Intercepting voice over ip communications and other data communications

ABSTRACT

Methods and apparatus for intercepting communications in an Internet Protocol (IP) network involve maintaining dialing profiles for respective subscribers to the IP network, each dialing profile including a username associated with the corresponding subscriber, and associating intercept information with the dialing profile of a subscriber whose communications are to be monitored. Intercept information will include determination information for determining whether to intercept a communication involving the subscriber, and destination information identifying a device to which intercepted communications involving the subscriber are to be sent. When the determination information meets intercept criteria communications are established with a media relay through which communications involving the subscriber will be conducted or are being conducted to cause the media relay to send a copy of the communications involving the subscriber to a mediation device specified by the destination information.

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication are hereby incorporated by reference under 37 CFR 1.57. Thisapplication is a continuation of U.S. patent application Ser. No.15/385,555, filed Dec. 20, 2016, which is a continuation of U.S. patentapplication Ser. No. 14/802,929, filed Jul. 17, 2015, and issued as U.S.Pat. No. 9,549,071, which is a continuation of patent application Ser.No. 13/863,306, filed Apr. 15, 2013, and issued as U.S. Pat. No.9,143,608, which is a continuation of U.S. patent application Ser. No.12/517,026, filed Mar. 5, 2010, and issued as U.S. Pat. No. 8,422,507,which is a national phase entry of PCT/CA2007/002150, filed Nov. 29,2007, and which claims the benefit of U.S. Provisional Application No.60/861,431 filed on Nov. 29, 2006, all of which are incorporated byreference in their entirety.

BACKGROUND Field

This development relates to data communications and methods andapparatus for intercepting data communications, particularly voice overIP data communications, in an IP network.

Description of the Related Art

The term “lawful intercept” is used to describe a procedure which allowslaw enforcement agencies to perform electronic surveillance oftelecommunications. Lawful intercept of telecommunications, particularlyphone calls, is premised on a notion that a law enforcement agency hasidentified a person of interest, obtained a legal authorization for thesurveillance (for example, a judicial or administrative warrant), andthen contacted the person's telecommunications service provider thatwill be required to provide the law enforcement agency with a real-timecopy of the person's communications. This real-time copy can then beused by the law enforcement agency to monitor or record the person'scommunications. Within the framework of traditional telecommunicationsnetworks, such as, for example, the Public Switched Telephone Network(PSTN) or cellular networks, lawful intercept generally presents apurely economic problem for the service providers that have to ensurethat sufficient interception equipment and dedicated links to the lawenforcement agencies have been deployed to satisfy lawful interceptrequirements mandated by law. However, in the context of Voice overInternet Protocol (VoIP) communications, in addition to the economicproblems mentioned above, lawful intercept presents significanttechnological challenges which often makes compliance with legallymandated lawful intercept requirements exceedingly difficult.

The problem lies in the very nature of the VoIP technology and theInternet Protocol (IP) networks (for example, the Internet) thatunderlie it.

Traditional telecommunications networks are “connection-oriented” or“circuit-switched”. Communications over such networks occur viadedicated “circuits”. Although the networks typically comprise aplurality of available parallel paths, when a circuit is established,only a single one of the available paths is picked. In situations wherea circuit has failure protection, a redundant path, also determined atthe time of the circuit establishment, can also be reserved. Once thecircuit is established, all communications traverse from end to end.Interception of such communications is easy as the service provider can“tap” the circuit at any point in the network that is under its lawfulcontrol.

In contrast to circuit-switched networks, IP-based networks are“connectionless” by design. A connectionless IP network essentiallycomprises a plurality of interconnected network devices (routers) whichestablish a plurality of paths from any point on the network to anyother point. Information that needs to traverse an IP network is dividedinto small “packets”, each one comprising an IP header containing sourceand destination addressing information, and service flags; and userpayload. The specific path that each packet in a communication betweenparties takes across an IP network is not determined in advance such asin a circuit-switched network. The path is defined on a hop-by-hop basis(router-by-router), each router at which the packet arrives examines thesource and destination addresses contained in the IP header and appliesa number of service variables such as hop-count (number of routersbetween the current router and the destination), latency and bandwidthof available links, and administrative considerations such asinter-provider agreements, to determine the next hop to which the packetwill be forwarded. Because the service variables change dynamically, forexample in response to a failure of a link in the network, the availablepaths may change significantly and it is impossible to reliably predictthe path or paths that the packets that comprise a specific a specificcommunication will traverse. Furthermore, it is not even possible topredict the order in which the packets will arrive at their destinationas the different paths taken may have different latency. While theplurality of available paths and out-of-order arrivals present noproblems to IP-based applications that usually keep track of the packetsequence to reassemble the communication, the same factors presentformidable problems for the lawful intercept of communication over IPnetworks, particularly lawful intercept of VoIP calls.

The problem of lawful intercept in VoIP systems is further exacerbatedby the distributed technologies often utilized in such systems. While aVoIP caller typically communicates with a VoIP call controller tofacilitate the connection to the VoIP callee, the actual communicationbetween the parties typically occurs by establishing a direct IPconnection between them using the User Datagram Protocol (UDP) toencapsulate audio information into IP packets. These packets may takeany available path across the IP network as described above. Even if aservice provider could place an interception device at every point inthe network through which a subscriber's packet could traverse, in orderto provide a useful copy of the communication to a law enforcementagency, the service provider would have to reassemble all of theintercepted packets at a single device and only then pass the result tothe law enforcement agency. In essence, the service provider would haveto mirror the functions of the callee VoIP telephone, except the packetsthat comprise the communication would have to be collected from multiplepoints in the network. The technological challenges and economic costsassociated with this proposition have thus far resulted in lack ofmeaningful lawful intercept capabilities in VoIP systems.

SUMMARY

In accordance with one aspect, there is provided a method forintercepting communications in an Internet Protocol (IP) network. Themethod involves maintaining dialing profiles for respective subscribersto the IP network, each dialing profile including a username associatedwith the corresponding subscriber. The method also involves associatingintercept information with the dialing profile of a subscriber whosecommunications are to be monitored, the intercept information includingdetermination information for determining whether to intercept acommunication involving the subscriber, and destination informationidentifying a device to which intercepted communications involving thesubscriber are to be sent. The method further involves, when thedetermination information meets intercept criteria, communicating with amedia relay through which the communications involving the subscriberwill be conducted or are being conducted to cause the media relay tosend a copy of the communications to a mediation device specified by thedestination information.

Associating intercept information may involve associating the interceptinformation with the dialing profile when communications involving thesubscriber are not in progress.

Associating intercept information may involve associating the interceptinformation when communications involving the subscriber are inprogress.

Associating the intercept information may involve populating interceptinformation fields in the dialing profile of the subscriber whosecommunications are to be monitored.

The method may involve producing a routing message for routingcommunications involving the subscriber through components of the IPnetwork and determining whether the determination information meets theintercept criteria prior to producing the routing message and includingat least some of the intercept information in the routing message whenthe determination information meets the intercept criteria.

Determining whether the determination information meets the interceptcriteria may involve determining whether a current date and time iswithin a range specified by the determination information.

The method may involve identifying a media relay through whichcommunications involving the subscriber will be conducted in response tothe routing message.

The method may involve pre-associating at least one media relay with thedialing profile of the subscriber whose communications are to bemonitored and identifying the media relay may involve identifying themedia relay pre-associated with the subscriber whose communications areto be monitored.

Pre-associating may involve populating media relay fields in the dialingprofile with an identification of at least one media relay.

The intercept information may be associated with the dialing profile ofthe subscriber whose communications are to be monitored, in response toreceipt of an intercept request message, and the intercept requestmessage may include the intercept information.

The method may involve invoking an intercept request message handler tofind a dialing profile associated with the subscriber whosecommunications are to be monitored, and to perform the step ofassociating the intercept information with the dialing profile, and todetermine whether the intercept criteria are met, and identify a mediarelay through which the communications are being conducted.

The method may involve maintaining active call records forcommunications in progress, and the active call records may include ausername identifier and a media relay identifier identifying the mediarelay through which the communications are being conducted andidentifying a media relay through which the communications are beingconducted may involve locating an active call record associated withcommunications of the subscriber whose communication are to be monitoredto find the media relay associated with the communications.

The method may involve maintaining direct-inward-dialing (DID) recordsassociating PST telephone numbers with usernames of users subscribing tothe IP network, and finding a dialing profile associated with thesubscriber whose communications are to be monitored may involve findinga username in a DID record bearing a PSTN number associated with thesubscriber whose communications are to be monitored. The username may beused to locate a dialing profile associated with the username.

In accordance with another aspect, there is provided an apparatus forintercepting communications in an Internet Protocol (IP) network. Theapparatus includes provisions for maintaining dialing profiles forrespective subscribers to the IP network, each dialing profile includinga username associated with the corresponding subscriber. The apparatusalso includes provisions for associating intercept information with thedialing profile of a subscriber whose communications are to bemonitored, the intercept information including determination informationfor determining whether to intercept a communication involving thesubscriber, and destination information identifying a device to whichintercepted communications involving the subscriber are to be sent. Theapparatus further includes provisions for communicating with a mediarelay through which the communications involving the subscriber will beconducted or are being conducted to cause the media relay to send a copyof the communications to a mediation device specified by the destinationinformation, when the determination information meets interceptcriteria.

The provisions for associating intercept information may be operablyconfigured to associate the intercept information with the dialingprofile when communications involving the subscriber are not inprogress.

The provisions for associating intercept information may be operablyconfigured to associate the intercept information when communicationsinvolving the subscriber are in progress.

The provisions for associating the intercept information may be operablyconfigured to populate intercept information fields in the dialingprofile of the subscriber whose communications are to be monitored.

The apparatus may further include provisions for producing a routingmessage for routing communications involving the subscriber throughcomponents of the IP network and provisions for determining whether thedetermination information meets the intercept criteria prior toproducing the routing message and the provisions for producing therouting message may be operably configured to include at least some ofthe intercept information in the routing message when the determinationinformation meets the intercept criteria.

The provisions for determining whether the determination informationmeets the intercept criteria may be operably configured to determinewhether a current date and time is within a range specified by thedetermination information.

The apparatus may further include provisions for identifying a mediarelay through which communications involving the subscriber will beconducted in response to the routing message.

The apparatus may further include provisions for pre-associating atleast one media relay with the dialing profile of the subscriber whosecommunications are to be monitored and the routing provisions may beoperably configured to identify from the dialing profile the media relaypre-associated with the subscriber whose communications are to bemonitored.

The provisions for pre-associating may be operably configured topopulate media relay fields in the dialing profile with anidentification of at least one media relay.

Provisions for associating the intercept information may be operablyconfigured to associate the intercept information associated with thedialing profile of the subscriber whose communications are to bemonitored, in response to receipt of an intercept request message,wherein the intercept request message may comprise the interceptinformation.

The apparatus may further include provisions for handling an interceptrequest message. The provisions for handling an intercept requestmessage may include provisions for finding a dialing profile associatedwith the subscriber whose communications are to be monitored. Theprovisions for finding a dialing profile may cooperate with theprovisions for associating the intercept information with the dialingprofile to cause the intercept information to be associated with thedialing profile. The provisions for handling an intercept requestmessage may include provisions for determining whether the interceptcriteria are met and provisions for identifying a media relay throughwhich the communications are being conducted.

The apparatus may further include provisions for maintaining active callrecords for communications in progress, the active call recordsincluding a username identifier and a media relay identifier identifyingthe media relay through which the communications are being conducted andthe provisions for identifying a media relay through which thecommunications are being conducted may be operably configured to locatean active call record associated with communications of the subscriberwhose communication are to be monitored to find the media relayassociated with the communications.

The apparatus may further include provisions for maintainingdirect-inward-dialing (DID) records associating PST telephone numberswith usernames of users subscribing to the IP network, and theprovisions for finding a dialing profile associated with the subscriberwhose communications are to be monitored may be operably configured tofind a username in a DID record bearing a PSTN number associated withthe subscriber whose communications are to be monitored and use theusername to locate a dialing profile associated with the username.

By employing a media relay, all VoIP communications traverse a point inthe VoIP system that is under a provider's control and at which thecommunications can be copied in real-time to a mediation device thatpasses the intercepted communication to a law enforcement agency.

By maintaining dialing profiles for respective subscribers andassociating intercept information of the type described, with thedialing profiles of subscribers whose communications are to bemonitored, the dialing profile can serve as the source of determinationinformation for determining whether or not communications involving thesubscriber will be monitored and for providing destination informationfor specifying where the copy of the communications is to be sent. Useof the dialing profile in this manner easily facilitates the dialingprofile to be considered a repository for intercept information for agiven subscriber and this repository can be addressed whether a call isbeing initiated or in progress, thereby simplifying control algorithmsbecause they can cooperate with a common source and format of data inthe dialing profile.

In another embodiment, there is a method for causing Internet Protocol(IP) communications to be intercepted in an IP network system in whichIP communications between a subscriber of the system and another partyoccur through a media relay to which the subscriber and the anotherparty address their IP communications destined for each other and whichrelays the IP communications between the subscriber and the anotherparty, the method comprising causing a call controller to receive arequest from the subscriber seeking to initiate communications betweenthe subscriber and the another party and to produce a request toestablish an IP communications channel between the subscriber and theanother party; and causing a call routing controller to receive from thecall controller said request to establish said IP communicationschannel; access a database in response to receiving said request fromsaid call controller, to locate a dialing profile associated with thesubscriber, said dialing profile comprising intercept determinationinformation and destination information, said intercept determinationinformation indicating whether an IP communication from the subscribershould be monitored and said destination information indicating where tosend monitored communications; and produce a routing message for receiptby the call controller and separate from any IP communication sentbetween the subscriber and the another party, for providing routinginformation for routing the IP communications through the media relay toenable the call controller to establish said IP communications channelthrough the media relay in response to the routing message; and whensaid determination information meets intercept criteria, cause saidrouting message to include at least some of said intercept determinationinformation and said destination information.

The IP communications may include at least one of audio data, pure data,video data, multimedia data, text messaging data and instant messagingdata. The method may further comprise causing said call controller tocommunicate with the media relay to cause the media relay to establish acommunication path for relaying IP communications between the subscriberand the another party; and when said intercept determination informationand said destination information are included in said routing message,produce a copy of said IP communications between the subscriber and theanother party, while the media relay relays communications between thesubscriber and the another party; and send said copy to a mediationdevice identified by said destination information in said routingmessage.

The method may further comprise associating said determinationinformation and said destination information with said dialing profilewhen communications involving said subscriber are not in progress. Themethod may further comprise associating said determination informationand said destination information with said dialing profile whencommunications involving said subscriber are in progress. Associatingsaid determination information and said destination information maycomprise populating intercept information fields in said dialing profileof a subscriber whose communications are to be monitored. Associatingsaid determination information and said destination information maycomprise populating intercept information fields in said dialing profileof a subscriber whose communications are to be monitored. Determiningwhether said determination information meets said intercept criteria maycomprise determining whether a current date and time is within a rangespecified by said determination information. Producing said routingmessage may comprise identifying a media relay through whichcommunications involving said subscriber will be conducted and includingan identification of said media relay in said routing message. Themethod may further comprise pre-associating at least one media relaywith said dialing profile associated with the subscriber whosecommunications are to be monitored and wherein identifying said mediarelay may comprise identifying said at least one media relaypre-associated with said subscriber whose communications are to bemonitored. Pre-associating may comprise populating media relay fields insaid dialing profile with an identification of said at least one mediarelay.

Associating said determination information and said destinationinformation may comprise associating said determination information andsaid destination information with said dialing profile of the subscriberwhose communications are to be monitored, in response to receipt of anintercept request message, wherein said intercept request message maycomprise said determination information and said destinationinformation. The method may further comprise invoking an interceptrequest message handler to a) find a dialing profile associated with thesubscriber whose communications are to be monitored; b) associate saiddetermination information and said destination information with saiddialing profile; and c) identify a media relay through which saidcommunications are being conducted. The dialing profile may include ausername identifier and may further comprise maintaining active callrecords for communications in progress, said active call records maycomprise a username identifier and a media relay identifier identifyingthe media relay through which said communications are being conductedand wherein identifying a media relay through which said communicationsare being conducted may comprise locating an active call recordassociated with a channel used by the subscriber whose communicationsare to be monitored to identify the media relay associated with saidchannel. The method may further comprise maintaining direct-inward-dial(DID) records associating Public Switched Telephone Network (PSTN)telephone numbers with usernames of users subscribing to said IPnetwork, and wherein finding a dialing profile associated with thesubscriber whose communications are to be monitored may comprise findinga username in a DID record bearing a PSTN number associated with thesubscriber whose communications are to be monitored and using saidusername to locate a dialing profile associated with said username. Themethod may further comprise causing the call controller to receivecommunications from the mediation device to cause the call controller tointeract with the call routing controller to access a dialing profile ofa subscriber whose communications are to be monitored and to enter saidintercept determination information and destination information intosaid dialing profile.

In another embodiment, there is a system for causing Internet Protocol(IP) communications to be intercepted in an IP network in which IPcommunications between a subscriber of said system and another partyoccur through a media relay to which the subscriber and the anotherparty address their IP communications destined for each other and whichrelays said IP communications between the subscriber and the anotherparty, the system comprising a call controller and a call routingcontroller in communication with the call controller; said callcontroller being operably configured to receive a request from thesubscriber seeking to initiate communications between the subscriber andthe another party and to produce a request to establish an IPcommunications channel between the subscriber and the another party andfor establishing said IP communications channel through the media relayin response to a routing message produced by said call routingcontroller; said call routing controller operably configured to receivefrom the call controller said request to establish said IPcommunications channel between the subscriber and the another party,access a database in response to receiving said request from said callcontroller to locate a dialing profile associated with the subscriber,said dialing profile comprising intercept determination information anddestination information, said intercept determination informationindicating whether an IP communication from the subscriber should bemonitored and said destination information indicating where to sendmonitored communications; and produce a routing message for receipt bythe call controller and separate from any IP communication sent betweenthe subscriber and the another party, for providing routing informationfor routing the IP communications through the media relay; and when saiddetermination information meets intercept criteria, cause said routingmessage to include at least some of said intercept determinationinformation and said destination information.

The IP communications may include at least one of audio data, pure data,video data, multimedia data, text messaging data and instant messagingdata. The call routing controller may be operably configured to respondto said routing message by communicating with the media relay to causethe media relay to establish a communication path to relay said IPcommunications between the subscriber and the another party; and whensaid intercept determination information and said destinationinformation are included in said routing message, produce a copy of saidIP communications between the subscriber and the another party, whilesaid media relay relays communications between the subscriber and theanother party; and send said copy to a mediation device identified bysaid destination information in said routing message. At least one ofsaid call controller and said call routing controller may be operablyconfigured to associate said intercept information with said dialingprofile when communications involving said subscriber are not inprogress. At least one of said call controller and said call routingcontroller may be operably configured to associate said interceptdetermination information with said dialing profile when communicationsinvolving said subscriber are in progress. At least one of said callcontroller and said call routing controller may be operably configuredto populate intercept information fields in said dialing profile of thesubscriber whose communications are to be monitored. At least one ofsaid call controller and said call routing controller may be operablyconfigured to populate intercept information fields in said dialingprofile of the subscriber whose communications are to be monitored. Atleast one of said call controller and said call routing controller maybe operably configured to determine whether a current date and time iswithin a range specified by said determination information. At least oneof said call controller and said call routing controller may be operablyconfigured to identify a media relay through which communicationsinvolving said subscriber will be conducted and to include anidentification of said media relay in said routing message. At least oneof said call controller and said call routing controller may be operablyconfigured to pre-associate at least one media relay with said dialingprofile of the subscriber whose communications are to be monitored andwherein at least one of said call controller and said call routingcontroller may be operably configured to identify from said dialingprofile said at least one media relay pre-associated with saidsubscriber whose communications are to be monitored. At least one ofsaid call controller and said call routing controller may be operablyconfigured to populate media relay fields in said dialing profile withan identification of at said least one media relay.

At least one of said call controller and said call routing controllermay be operably configured to associate said intercept informationassociated with said dialing profile of the subscriber whosecommunications are to be monitored, in response to receipt of anintercept request message, wherein said intercept request message maycomprise said intercept information. At least one of said callcontroller and said call routing controller may be operably configuredto a) find a dialing profile associated with the subscriber whosecommunications are to be monitored, b) cause said intercept informationto be associated with said dialing profile; and c) identify a mediarelay through which said communications are being conducted. The dialingprofile may include a username identifier and wherein at least one ofsaid call controller and said call routing controller may be operablyconfigured to maintain active call records for communications inprogress, said active call records may comprise a username identifierand a media relay identifier identifying a media relay through whichsaid communications are being conducted and wherein said means foridentifying a media relay may be operably configured to locate an activecall record associated with a channel used by the subscriber whosecommunications are to be monitored to identify the media relayassociated with said channel. At least one of said call controller andsaid call routing controller may be operably configured to accessdirect-inward-dial (DID) records associating Public Switched TelephoneNetwork (PSTN) telephone numbers with usernames of users subscribing tosaid IP network, and wherein at least one of said call controller andsaid call routing controller may be operably configured to find ausername in a DID record bearing a PSTN number associated with thesubscriber whose communications are to be monitored and use saidusername to locate a dialing profile associated with said username. Thecall controller may be operably configured to receive communicationsfrom the mediation device to cause the call controller to interact withthe call routing controller to access a dialing profile of a subscriberwhose communications are to be monitored and to enter said interceptdetermination information and destination information into said dialingprofile.

In yet another embodiment, there is a method for causing InternetProtocol (IP) communications to be intercepted in an IP network systemin which IP communications between a subscriber of said system andanother party occur through a media relay to which the subscriber andthe another party address their IP communications destined for eachother and which relays said IP communications between the subscriber andthe another party, the method comprising in response to a request toestablish an IP communications channel between the subscriber and theanother party locating a dialing profile associated with the subscriber,said dialing profile comprising intercept determination information anddestination information, said intercept determination informationindicating whether an IP communication from the subscriber should bemonitored and said destination information indicating where to sendmonitored communications; producing a routing message for receipt by acall controller and separate from any IP communication sent between thesubscriber and the another party, for routing the IP communicationsthrough the media relay and when said determination information meetsintercept criteria, causing said routing message to include at leastsome of said intercept determination information and said destinationinformation.

The IP communications may include at least one of audio data, pure data,video data, multimedia data, text messaging data and instant messagingdata. The method may further comprise responding to said routing messageby communicating with the media relay to cause the media relay toestablish a communication path for relaying IP communications betweenthe subscriber and the another party; and when said interceptdetermination information and said destination information are includedin said routing message, produce a copy of said IP communicationsbetween the subscriber and the another party, while the media relayrelays communications between the subscriber and the another party; andsend said copy to a mediation device identified by said destinationinformation in said routing message. The method may further compriseassociating said determination information and said destinationinformation with said dialing profile when communications involving saidsubscriber are not in progress. The method may further compriseassociating said determination information and said destinationinformation with said subscriber dialing profile when communicationsinvolving said subscriber are in progress. Associating saiddetermination information and said destination information may comprisepopulating intercept information fields in said dialing profile of asubscriber whose communications are to be monitored. Associating saiddetermination information and said destination information may comprisepopulating intercept information fields in said dialing profile of asubscriber whose communications are to be monitored. Determining whethersaid determination information meets said intercept criteria maycomprise determining whether a current date and time is within a rangespecified by said determination information. Producing said routingmessage may comprise identifying a media relay through whichcommunications involving said subscriber will be conducted and includingan identification of said media relay in said routing message. Themethod may further comprise pre-associating at least one media relaywith said dialing profile associated with the subscriber whosecommunications are to be monitored and wherein identifying said mediarelay may comprise identifying said at least one media relaypre-associated with said subscriber whose communications are to bemonitored. Pre-associating may comprise populating media relay fields insaid dialing profile with an identification of said at least one mediarelay.

Associating said determination information and said destinationinformation may comprise associating said determination information andsaid destination information with said dialing profile of the subscriberwhose communications are to be monitored, in response to receipt of anintercept request message, wherein said intercept request message maycomprise said determination information and said destinationinformation. The method may further comprise invoking an interceptrequest message handler to a) find a dialing profile associated with thesubscriber whose communications are to be monitored; b) associate saiddetermination information and said destination information with saiddialing profile; and c) identify a media relay through which saidcommunications are being conducted. The dialing profile may include ausername identifier and may further comprise maintaining active callrecords for communications in progress, said active call records maycomprise a username identifier and a media relay identifier identifyingthe media relay through which said communications are being conductedand wherein identifying a media relay through which said communicationsare being conducted may comprise locating an active call recordassociated with a channel used by the subscriber whose communicationsare to be monitored to identify the media relay associated with saidchannel. The method may further comprise maintaining direct-inward-dial(DID) records associating Public Switched Telephone Network (PSTN)telephone numbers with usernames of users subscribing to said IPnetwork, and wherein finding a dialing profile associated with thesubscriber whose communications are to be monitored may comprise findinga username in a DID record bearing a PSTN number associated with thesubscriber whose communications are to be monitored and using saidusername to locate a dialing profile associated with said username. Themethod may further comprise causing the call controller to receivecommunications from the mediation device to cause the dialing profile ofa subscriber whose communications are to be monitored and to receivesaid intercept determination information and destination information.

Other aspects and features will become apparent to those ordinarilyskilled in the art upon review of the following description of specificembodiments of the development in conjunction with the accompanyingfigures.

BRIEF DESCRIPTION OF THE DRAWINGS

In drawings which illustrate embodiments of the development,

FIG. 1 is a block diagram of a system according to a first embodiment;

FIG. 2 is a block diagram of a caller VoIP telephone according to thefirst embodiment;

FIG. 3 is a schematic representation of a SIP Invite message transmittedbetween the caller telephone and a call controller (CC) shown in FIG. 1;

FIG. 4 is a block diagram of the call controller shown in FIG. 1;

FIG. 5 is a flowchart of a process executed by the call controller shownin FIG. 1;

FIG. 6 is a schematic representation of a routing controller (RC)request message produced by the call controller shown in FIG. 1;

FIG. 7 is a block diagram of a routing controller (RC) processor circuitof the system shown in FIG. 1;

FIGS. 8A-8D are flowcharts of a RC Request message handler executed bythe RC processor circuit shown in FIG. 7;

FIG. 9 is a tabular representation of a dialing profile stored in adatabase accessible by the RC shown in FIG. 1;

FIG. 10 is a tabular representation of a dialing profile for a Vancouversub scriber;

FIG. 11 is a tabular representation of a dialing profile for a Calgarysubscriber;

FIG. 12 is a tabular representation of a dialing profile for a Londonsub scriber;

FIG. 13 is a tabular representation of a direct-inward-dialing (DID)bank table record stored in the database shown in FIG. 1;

FIG. 14 is a tabular representation of an exemplary DID bank tablerecord for the London subscriber referenced in FIG. 12;

FIG. 15 is a tabular representation of a routing message transmittedfrom the routing controller to the call controller shown in FIG. 1;

FIG. 16 is a tabular representation of a routing message buffer holdinga routing message for routing a call to the London callee referenced inFIG. 12;

FIG. 16A is a tabular representation of a routing message buffer holdinga message for routing a call to the London callee and to a lawenforcement agency for the purpose of lawful intercept;

FIG. 17 is a tabular representation of a prefix to supernode tablerecord stored in the database shown in FIG. 1;

FIG. 18 is a tabular representation of a prefix to supernode tablerecord that would be used for the Calgary callee referenced in FIG. 11;

FIG. 19 is a tabular representation of a master list record stored in amaster list table in the database shown in FIG. 1;

FIG. 20 is a tabular representation of an exemplary populated masterlist record;

FIG. 21 is a tabular representation of a suppliers list record stored inthe database shown in FIG. 1;

FIG. 22 is a tabular representation of a specific supplier list recordfor a first supplier;

FIG. 23 is a tabular representation of a specific supplier list recordfor a second supplier;

FIG. 24 is a tabular representation of a specific supplier list recordfor a third supplier;

FIG. 25 is a tabular representation of a routing message, held in arouting message buffer, identifying to the routing controller aplurality of possible suppliers that may carry the call;

FIG. 25A is a tabular representation of a routing message held in arouting message buffer, with lawful intercept fields appended;

FIG. 26 is a tabular representation of a call block table record;

FIG. 27 is a tabular representation of a call block table record for theCalgary callee;

FIG. 28 is a tabular representation of a call forwarding table record;

FIG. 29 is a tabular representation of an exemplary call forwardingtable record specific for the Calgary callee;

FIG. 30 is a tabular representation of a voicemail table recordspecifying voicemail parameters to enable the caller to leave avoicemail message for the callee;

FIG. 31 is a tabular representation of an exemplary voicemail tablerecord for the Calgary callee;

FIG. 32 is a tabular representation of an exemplary routing message,held in a routing message buffer, indicating call forwarding numbers anda voicemail server identifier;

FIG. 32A is a tabular representation of an exemplary routing message,held in a routing message buffer, indicating call forwarding numbers anda voicemail server identifier with caller lawful intercept fieldsappended;

FIG. 32B is a tabular representation of an exemplary routing message,held in a routing message buffer, indicating call forwarding numbers anda voicemail server identifier with caller and callee lawful interceptfields appended;

FIG. 33 is a flowchart of a routing message handler process executed bythe call controller;

FIG. 34 is a schematic representation of messages exchanged duringexecution of process for establishing audio paths between telephones anda media relay;

FIG. 35 is a tabular representation of an active call record maintainedby the call controller of FIG. 1;

FIG. 36 is a tabular representation of an active call record maintainedby the routing controller of FIG. 1;

FIG. 37 is a tabular representation of a SIP Invite message transmittedfrom the call controller to the mediation device;

FIG. 38 is a tabular representation of a SIP OK message transmitted fromthe mediation device to the call controller;

FIG. 39 is a tabular representation of a SIP Bye message transmittedfrom either of the telephones shown in FIG. 1 to the call controller;

FIG. 40 is a tabular representation of a SIP Bye message sent to thecall controller from the Calgary callee;

FIG. 41 is a flowchart of a process executed by the call controller forproducing a RC stop message in response to receipt of a SIP Bye message;

FIG. 42 is a tabular representation of an exemplary RC Call Stopmessage;

FIG. 43 is a tabular representation of an exemplary RC Call Stop messagefor the Calgary callee;

FIG. 44 is a flowchart of a routing controller Law Enforcement Authorityrequest message handler executed by the routing controller shown in FIG.1;

FIG. 45 is a flowchart of a call controller in-call intercept messagehandler executed by the call controller shown in FIG. 1;

FIG. 46 is a flowchart of a routing controller in-call intercept shutdown routine executed by the routing controller shown in FIG. 1;

FIG. 47 is a flowchart of a call controller cease intercept messagehandler routing executed by the call controller shown in FIG. 1.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Referring to FIG. 1, a system for making voice over IP telephone callsis shown generally at 10. The system includes a first supernode showngenerally at 11 and a second supernode shown generally at 21. The firstsupernode 11 is located in a geographical area, such as Vancouver B.C.,for example and the second supernode 21 is located in London England,for example. Different supernodes may be located in differentgeographical regions throughout the world to provide telephone serviceto subscribers in respective regions. These supernodes may be incommunication with each other through high speed/high data throughputlinks including optical fiber, satellite and/or cable links, forexample, forming a system backbone. These supernodes may alternativelyor in addition be in communication with each other through conventionalInternet services. In the embodiment shown, data communication media forproviding for data communications between the first and secondsupernodes 11 and 21 are shown generally at 23 and may include very highspeed data links, for example.

In the embodiment shown, the Vancouver supernode 11 provides telephoneservice to a geographical region comprising Western Canadian customersfrom Vancouver Island to Ontario and includes a Vancouver subscriber anda Calgary subscriber. Another supernode (not shown) may be located inEastern Canada to provide services to subscribers in that area.

Other, smaller supernodes similar to the type shown may also be employedwithin the geographical area serviced by a supernode, to provide forcall load sharing, for example within a region of the geographical areaserviced by the supernode. However, in general, all supernodes aresimilar and have the properties described below in connection with theVancouver supernode 11.

In this embodiment, the Vancouver supernode includes a call controller(CC) 14, a routing controller (RC) 16, a database 18, a media relay 17and one or more mediation devices (MD), only one of which is shown at31. Subscribers such as the Vancouver subscriber and the Calgarysubscriber communicate with the Vancouver supernode 11 using their ownInternet Service Providers (ISPs) 13 and 19 which route Internet trafficfrom these subscribers over the Internet. To these subscribers theVancouver supernode 11 is accessible at a pre-determined IP address or afully qualified domain name (FQDN) so that it can be accessed in theusual way through a subscriber's ISP. The subscriber in the city ofVancouver uses a telephone 12 that is capable of communicating with theVancouver supernode 11 using Session Initiation Protocol (SIP) messagesand the Calgary subscriber uses a similar telephone 15, to communicatewith the Vancouver supernode from Calgary, AB.

It should be noted that throughout the description of the embodiments ofthis development, the IP/UDP addresses of all elements such as thecaller and callee telephones, call controller, media relay, and anyothers, will be assumed to be valid IP/UDP addresses directly accessiblevia the Internet or a private IP network, for example, depending on thespecific implementation of the system. As such, it will be assumed, forexample, that the caller and callee telephones will have IP/UDPaddresses directly accessible by the call controllers and the mediarelays on their respective supernodes, and that will not be obscured byNetwork Address Translation (NAT) or similar mechanisms. In other words,the IP/UDP information contained in SIP messages (for example the SIPInvite message or the RC Request message which will be described below)will match the IP/UDP addresses of the IP packets carrying these SIPmessages.

It will be appreciated that in many situations, the IP addressesassigned to various elements of the system may be in a private IPaddress space, and thus not directly accessible from other elements.Furthermore, it will also be appreciated that NAT is commonly used toshare a “public” IP address between multiple devices, for examplebetween home PCs and IP telephones sharing a single Internet connection.For example, a home PC may be assigned an IP address such as192.168.0.101 and a Voice over IP telephone may be assigned an IPaddress of 192.168.0.103. These addresses are located in so called“non-routable” address space and cannot be accessed directly from theInternet. In order for these devices to communicate with other computerslocated on the Internet, these IP addresses have to be converted into a“public” IP address, for example 24.10.10.123 assigned to the subscriberby the Internet Service Provider, by a device performing NAT, typicallya home router. In addition to translating the IP addresses, the NATtypically also translates UDP port numbers, for example an audio pathoriginating at an IP telephone and using a UDP port 12378 at its privateIP address may have been translated to a UDP port 23465 associated withthe public IP address of the NAT device. In other words, when a packetoriginating from the above IP telephone arrives at an Internet-basedsupernode, the source IP/UDP address contained in the IP packet headerwill be 24.10.10.1:23465, whereas the source IP/UDP address informationcontained in the SIP message inside this IP packet will be192.168.0.103:12378. The mismatch in the IP/UDP addresses may cause aproblem for SIP-based systems because, for example, a supernode willattempt to send messages to a private address of a telephone—themessages will never get there.

It will be appreciated that a number of methods are available toovercome this problem. For example, the SIP NATHelper open sourcesoftware module may run on the supernode to correlate public IP/UDPaddress contained in the headers of the IP packets arriving from SIPdevices with private IP/UDP addresses in the SIP messages contained inthese packets. Therefore, the embodiments of the development describedbelow will function whether or not any of the elements of the system arelocated behind NAT devices that obscure their real IP/UDP addresses.

Referring to FIG. 1, in an attempt to make a call by the Vancouvertelephone 12 to the Calgary telephone 15, for example, the Vancouvertelephone sends a SIP Invite message to the Vancouver supernode 11 andin response, the call controller 14 sends an RC Request message to therouting controller 16 which makes various enquiries of the database 18to produce a routing message which is sent to the call controller 14.The call controller 14 then causes a communications link including audiopaths to be established through the media relay 17 which may include thesame Vancouver supernode 11, a different supernode or a communicationssupplier gateway, for example, to carry voice traffic to and from thecall recipient or callee. Subject to certain conditions being satisfied,as will be described below, when lawful intercept of data is to occur,data on the audio paths is copied to the mediation device 31 which mayprovide for real time listening of the audio data or recording of same.

Subscriber Telephone

Referring to FIG. 2, in this embodiment, the telephones 12, 15, 22 and25 each includes a processor circuit shown generally at 30 comprising amicroprocessor 32, program memory 34, an input/output (I/O) interface36, parameter memory 38 and temporary memory 40. The program memory 34,I/O interface 36, parameter memory 38 and temporary memory 40 are all incommunication with the microprocessor 32. The I/O interface 36 has adial input 42 for receiving a dialed telephone number from a keypad, forexample, or from a voice recognition unit or from pre-stored telephonenumbers stored in the parameter memory 38, for example. For simplicity,a box labelled dialing functions 44 represents any device capable ofinforming the microprocessor 32 of a callee identifier, e.g., a calleetelephone number.

The microprocessor 32 stores the callee identifier in a dialed numberbuffer 41. In the case of the Vancouver subscriber for example, thedialed number may be 2001 1050 2222, identifying the Calgary subscriberor the dialed number may be a PSTN number, for example. The I/Ointerface 36 also has a handset interface 46 for receiving and producingsignals from and to a handset 45 that the user may place to his ear. Thehandset interface 46 may include a BLUETOOTH™ wireless interface, awired interface or speakerphone, for example. The handset 45 acts as atermination point for an audio path (not shown) which will beappreciated later.

The I/O interface 36 also has a network interface 48 to an IP networkwhich may provide a high speed Internet connection, for example, and isoperable to connect the telephone to an ISP. The network interface 48also acts as a part of the audio path, as will be appreciated later.

The parameter memory 38 has a username field 50, a password field 52, anIP address field 53 and a SIP proxy address field 54. The username field50 is operable to hold a username, which, for the Vancouver subscriber,is 2001 1050 8667. The username is assigned upon subscription orregistration into the system and, in this embodiment includes a twelvedigit number having a continent code 61, a country code 63, a dealercode 70 and a unique number code 74. The continent code 61 is comprisedof the first or left-most digit of the username in this embodiment. Thecountry code 63 is comprised of the next three digits. The dealer code70 is comprised of the next four digits and the unique number code 74 iscomprised of the last four digits. The password field 52 holds apassword of up to 512 characters, in this example. The IP address field53 stores an IP address and UDP port number of the telephone 12, which,for this explanation, is 192.168.0.20:12345. The SIP proxy address field54 stores an IP address of a SIP proxy which may be provided to thetelephone 12 through the network interface 48 as part of a registrationprocedure.

The program memory 34 stores blocks of codes for directing themicroprocessor 32 to carry out the functions of the telephone, one ofwhich includes a firewall block 56 which provides firewall functions tothe telephone, to prevent unauthorized access through the networkconnection to the microprocessor 32 and memories 34, 38 and 40. Theprogram memory 34 also stores call ID codes 57 for establishing a callID. The call ID codes 57 direct the microprocessor 32 to produce callidentifiers having the format of a hexadecimal string and an IP addressof the telephone stored in the IP address field 53. Thus, an exemplarycall identifier for a call might be FF10@192.168.0.20.

Generally, in response to activating the handset 45 and using thedialing function 44, the microprocessor 32 produces and sends a SIPInvite message as shown in FIG. 3, to the call controller 14 shown inFIG. 1.

Referring to FIG. 3, the SIP Invite message includes a caller identifierfield 60, a callee identifier field 62, a digest parameters field 64, acall identifier field 65, a caller IP address field 67 and a caller UDPport field 69. In this embodiment, the caller identifier field 60includes the username 2001 1050 8667, which is the username stored inthe username field 50 of the parameter memory 38 in the Vancouvertelephone 12 shown in FIG. 2. In addition, as an example, referring backto FIG. 3, the callee identifier field 62 includes the username 20011050 2222 which is the dialed number of the Calgary subscriber stored inthe dialed number buffer 41 shown in FIG. 2. The digest parameters field64 includes digest parameters and the call identifier field 65 includesa code comprising a generated prefix code (FF10) and a suffix which isthe IP address of the telephone 12 stored in the IP address field 53.The caller IP address field 67 holds the IP address assigned to thetelephone, in this embodiment 192.168.0.20, and the caller UDP portfield 69 includes a UDP port identifier identifying a UDP port to whichaudio data is to be sent for reception by the caller's telephone.

Call Controller

Referring to FIG. 4, a call controller circuit of the call controller 14(FIG. 1) is shown in greater detail at 100. The call controller circuit100 includes a microprocessor 102, program memory 104 and an I/Ointerface 106. The call controller circuit 100 may include a pluralityof microprocessors, a plurality of program memories and a plurality ofI/O interfaces to be able to handle a large volume of calls. However,for simplicity, the call controller circuit 100 will be described ashaving only one microprocessor, program memory and I/O interface, itbeing understood that there may be more.

Generally, the I/O interface 106 includes an input 108 for receivingmessages, such as the SIP Invite message shown in FIG. 3, from thetelephone shown in FIG. 2. The I/O interface 106 also has an RC Requestmessage output 110 for transmitting an RC Request message to the routingcontroller 16 of FIG. 1, an RC message input 112 for receiving routingmessages from the routing controller 16 (FIG. 1), a media relay (MR)output 114 for transmitting messages to the media relay (FIG. 1) toadvise the media relay to establish an audio path, and a MR input 116for receiving messages from the media relay to which a message has beensent to attempt to establish the audio path. The I/O interface 106further includes a SIP output 118 for transmitting SIP messages to thetelephone 12 (FIG. 1) to advise the telephone of the IP address of themedia relay 17 (FIG. 1) which will establish the audio path. The I/Ointerface 106 further includes mediation device input 119 and output 121for communicating with the mediation device 31 (FIG. 1).

While certain inputs and outputs have been shown as separate, it will beappreciated that some may be associated with a single IP address and TCPor UDP port. For example, the messages sent and received from therouting controller 16 may be transmitted and received at the same singleIP address and TCP or UDP port.

The program memory 104 of the call controller circuit 100 includesblocks of code for directing the microprocessor 102 to carry out variousfunctions of the call controller 14. For example, these blocks of codeinclude a first block 120 for causing the call controller circuit 100 toexecute a SIP Invite-to-RC request process to produce an RC Requestmessage in response to a received SIP Invite message. In addition, thereis a Routing Message Handler block 122 which causes the call controllercircuit 100 to engage the mediation device and/or execute a callhandling routine to establish audio paths through a media relay toestablish the call. The program memory 104 further includes an in-callintercept message handler 1450 for intercepting a call in progress and acease intercept message handler 1520 for ceasing the interception of acall in progress.

Referring to FIG. 5, the SIP Invite-to-RC Request process is shown inmore detail at 120. On receipt of a SIP Invite message of the type shownin FIG. 3, block 132 of FIG. 5 directs the call controller circuit 100of FIG. 4 to authenticate the user operating the telephone from whichthe SIP Invite message originated. This may be done, for example, byprompting the user for a password, by sending a message back to thetelephone 12 which is interpreted at the telephone as a request forpassword entry or the password may automatically be sent to the callcontroller 14 from the telephone, in response to the message. The callcontroller 14 may then make enquiries of databases to which it hasaccess, to determine whether or not the user's password matches apassword stored in the database. Various functions may be used to passencryption keys or hash codes back and forth to ensure the securetransmission of passwords.

Should the authentication process fail, the call controller circuit 100is directed to an error handling block 134 which causes messages to bedisplayed at the telephone 12 to indicate that there was anauthentication error. If the authentication process is successful, block131 directs the call controller circuit 100 to determine whether or notthe contents of the caller identifier field 60 of the SIP Invite messageis a validly formatted IP address. If it is a valid IP address, thenblock 133 directs the call controller circuit 100 to associate a typecode with the call to indicate that the call type is a third partyinvite.

If at block 131 the caller identifier field 60 contents do not identifyan IP address, then block 135 directs the call controller circuit 100 toassociate a type code with the call to indicate the call type is aregular SIP Invite message. Then, block 136 directs the call controllercircuit 100 to establish a call ID by assigning the call ID provided inthe call identifier field 65 of the SIP Invite message from thetelephone 12, and at block 138 the call controller circuit is directedto produce an RC Request message of the type shown in FIG. 6 thatincludes that call ID. Referring back to FIG. 5, block 139 then directsthe call controller circuit 100 to send the RC Request message to therouting controller 16.

Referring to FIG. 6, an RC Request message is shown generally at 150 andincludes a caller identifier field 152, a callee identifier field 154, adigest field 156, a call ID field 158 and a type field 160. The caller,callee, digest, and call identifier fields 152, 154, 156 and 158 containcopies of the caller, callee, digest parameters and call ID fields 60,62, 64 and 65 of the SIP Invite message 59 shown in FIG. 3. The typefield 160 contains the type code established at block 133 or 135 of FIG.5 to indicate whether the call is from a third party or systemsubscriber, respectively. The callee identifier field 154 may include aPSTN number or a system subscriber username as shown, for example.

Routing Controller

Referring to FIG. 7, the routing controller 16 is shown in greaterdetail and includes a routing controller processor circuit showngenerally at 200. The RC processor circuit 200 includes a microprocessor202, program memory 204, a table memory 206 and an I/O interface 208,all in communication with the processor. There may be a plurality ofprocessor circuits (202), memories (204), etc.

The I/O interface 208 includes a database output port 210 through whicha request to the database 18 (FIG. 1) can be made and includes adatabase response port 212 for receiving a reply from the database. TheI/O interface 208 further includes an RC Request message input 214 forreceiving the RC Request message from the call controller 14 andincludes a routing message output 216 for sending a routing message backto the call controller 14.

The program memory 204 includes blocks of codes for directing the RCprocessor circuit 200 to carry out various functions of the routingcontroller 16. One of these blocks implements an RC Request messagehandler process 250 which directs the RC to produce a routing message inresponse to a received RC Request message of the type shown at 150 inFIG. 6. Referring back to FIG. 7, the program memory 204 furtherincludes a Law Enforcement Authority (LEA) request message handler 1400and an in-call intercept shut down routine 1500.

The RC Request message handler process 250 is shown in greater detail inFIGS. 8A through 8D.

RC Request Message Handler

Referring to FIG. 8A, the RC Request message handler process 250 beginswith a first block 252 that directs the RC processor circuit 200 (FIG.7) to store the contents of the RC Request message 150 (FIG. 6) inbuffers. Block 254 then directs the RC processor circuit 200 to use thecontents of the caller identifier field 152 in the RC Request messageshown in FIG. 6, to locate and retrieve a dialing profile for the callerfrom the database 18.

The routing controller maintains, in the database, a dialing profile foreach subscriber to the system. Referring to FIG. 9, an exemplary dialingprofile is shown generally at 256 and includes system fields including ausername field 258, a domain field 260, a national dialing digits (NDD)field 262, an IDDs (IDD) field 264, a country code field 266, a localarea codes field 267, a caller minimum local length field 268, a callermaximum local length field 270 and a reseller field 273.

The exemplary dialing profile further includes lawful intercept relatedfields including a lawful intercept (LI) flag field 702, at least onemediation device field 704, at least one warrant ID field 706, andintercept period start and stop date/time fields 708 and 710. The LIflag field 702, the warrant ID filed 706 and the LI start/stop fields708 and 710 may be regarded as determination information fields fordetermining whether to intercept a communication involving thesubscriber and the MD1 address field 704 may be regarded as adestination information field for identifying a device to whichintercepted communications involving the subscriber are to be sent.

The system fields (258, 260, 262, 264, 266, 267, 268, 270, 273) areassigned values by a system operator or are assigned automaticallyaccording to pre-defined algorithms (not shown) when a user registerswith the system to become a subscriber. The lawful intercept fields(702, 704, 706, 708, 710) are assigned values in response tocommunications with one or more authorized devices and may be populatedat any time regardless of whether or not communications involving thesubscriber are in progress.

For example, referring back to FIG. 1 the mediation device 31 may beregarded as an authorized device operated by a law enforcement authority293. A communications channel between the call controller 14 and themediation device 31 may be established to permit the mediation device tocommunicate with the call controller to cause the call controller tocommunicate with the routing controller 16 to find a subscriber recordin the database 18 which is associated with a subscriber for which awarrant for lawful intercept has been obtained. For example, once awarrant identifying a user and permitting lawful intercept of thatuser's communications has been received by the law enforcement authority293, that authority can use its own computers to communicate with themediation device 31 to cause the mediation device to communicate withthe call controller 14 to cause the call controller to interact with therouting controller 16 to access a dialing profile (FIG. 9) for the userspecified in the warrant and load the lawful intercept fields (702, 704,706, 708, 710) with data that sets the lawful intercept flag field 702to “on”, stores an IP address of the mediation device 31 in the MD1address field 704, loads the warrant ID field 706 with an identifier ofthe warrant and loads the start and stop fields 708 and 710 with startand stop dates and times to specify a period during which lawfulintercept of communications of the identified user may occur accordingto the warrant. Thus, intercept information is associated with thedialing profile by the routing controller, in response to information itreceives from the call controller.

A plurality of groups of lawful intercept fields of the type shown maybe added, each group being added by a different authorized device, forexample, if several different law enforcement agencies operating thesame or different mediation devices have warrants to monitorcommunications of a user. Alternatively the authorized device mayinclude a handover interface operable to communicate with the callcontroller or routing controller to access the database to load thelawful intercept fields associated with a subscriber of interest.

An exemplary dialing profile for the Vancouver subscriber is showngenerally at 276 in FIG. 10 and indicates that the username fieldincludes the username 2001 1050 8667 which is the same as the contentsof the username field 50 in the Vancouver telephone 12 shown in FIG. 2.

Referring back to FIG. 10, the domain field 260 includes a domain nameas shown at 282, including a supernode type identifier 284, a locationcode identifier 286, a system provider identifier 288 and a top leveldomain identifier 290, identifying a domain or supernode associated withthe user identified by the contents of the username field 258.

In this embodiment, the supernode type identifier 284 includes the code“sp” identifying a supernode and the location code identifier 286identifies the supernode as being in Vancouver (YVR). The systemprovider identifier 288 identifies the company supplying the service andthe top level domain identifier 290 identifies the “com” domain.

The national dialing digit (NDD) field 262 in this embodiment includesthe digit “1” and, in general, includes a digit specified by theInternational Telecommunications Union-TelecommunicationsStandardization Sector (ITU-T) E.164 Recommendation which assignsnational dialing digits to certain countries. Herein numbering sequencescompliant with this standard will be regarded as “E.164” numbers.

The International Dialing Digit (IDD) field 264 includes the code 011and in general includes a code assigned by the ITU-T according to thecountry or geographical location of the user.

The country code field 266 includes the digit “1” and in generalincludes a number assigned by the ITU-T to represent the country inwhich the user is located.

The local area codes field 267 includes the numbers 604 and 778 andgenerally includes a list of area codes that have been assigned by theITU-T to the geographical area in which the subscriber is located. Thecaller minimum and maximum local number length fields 268 and 270 holdthe number 10 representing minimum and maximum local number lengthspermitted in the area code(s) specified by the contents of the localarea codes field 267. The reseller field 273 holds a code identifying aretailer of the telephone services, and in the embodiment shown, theretailer is “Klondike”.

Initially, the lawful intercept fields shown in FIG. 9 might not beincluded in the dialing profile and may be added as described above, bythe mediation device 31, in the event a warrant is obtained to interceptthe user's calls. Alternatively, the lawful intercept fields may beincluded, but populated with null values until modified by a mediationdevice 31.

A dialing profile of the type shown at 256 in FIG. 9 is producedwhenever a user registers with the system or agrees to become asubscriber to the system. Thus, for example, a user wishing to subscribeto the system may contact an office maintained by a system operator andpersonnel in the office may ask the user certain questions about hislocation and service preferences, whereupon tables can be used toprovide office personnel with appropriate information to be entered intothe username, domain, NDD, IDD, country code, local area codes andcaller minimum and maximum local length fields 258, 260, 262, 264, 266,267, 268, 270 to establish a dialing profile for the user.

Referring to FIGS. 11 and 12, dialing profiles for subscribers inCalgary and London, respectively for example, are shown.

In addition to creating dialing profiles, optionally when a userregisters with the system, a direct inward dialing (DID) record of thetype shown at 268 in FIG. 13 is added to a direct inward dialing tablein the database 18 to associate the username with a host name of thesupernode with which the user is associated and with an E.164 number onthe PSTN network.

In this embodiment, the DID bank table records include a username field281, a user domain field 272 and a DID field 274, for holding theusername, hostname of the supernode, and an E.164 number respectively.

A DID bank table record for the London subscriber is shown generally at291 in FIG. 14.

In addition to creating dialing profiles and DID records when a userregisters with the system, call blocking records of the type shown inFIG. 26, call forwarding records of the type shown in FIG. 28 andvoicemail records of the type shown in FIG. 30 may be stored in thedatabase 18 when a new subscriber is added to the system.

Referring back to FIG. 8A, after being directed at block 254 to retrievea dialing profile for the caller, a dialing profile such as shown at 276in FIG. 10 is retrieved and the RC processor circuit 200 is directed toperform certain checks on the callee identifier provided by the contentsof the callee identifier field 154 of the RC Request message shown inFIG. 6. These checks are shown in greater detail in FIG. 8B.

Referring to FIG. 8B, the RC processor circuit 200 is directed to afirst block 257 that causes it to determine whether a digit pattern ofthe callee identifier 154 provided in the RC Request message includes apattern that matches the contents of the IDD field 264 in the callerdialing profile 276 shown in FIG. 10. If so, then block 259 directs theRC processor circuit 200 to set a call type code identifier (not shown)to indicate that the call is a long distance call, e.g., from theVancouver subscriber to the London subscriber, and block 261 directs theRC processor circuit 200 to produce a reformatted callee identifier byreformatting the callee identifier into a predetermined target format.In this embodiment, this is done by removing the pattern of digitsmatching the IDD field contents 264 of the caller dialing profile 276 toeffectively shorten the number. Then, block 263 directs the RC processorcircuit 200 to determine whether or not the reformatted calleeidentifier meets criteria establishing it as a number compliant with theE.164 Recommendation set by the ITU-T and if the length does not meetthis criteria, block 265 directs the RC processor circuit 200 to sendback to the call controller 14 a message indicating that the length ofthe call identifier is not correct. The process 250 is then ended. Atthe call controller 14, routines may respond to the incorrect lengthmessage by transmitting a message back to the telephone 12 to indicatethat an invalid number has been dialed.

Still referring to FIG. 8B, if the length of the reformatted calleeidentifier meets the criteria set forth at block 263, block 269 directsthe RC processor circuit 200 to determine whether or not the reformattedcallee identifier is associated with a direct inward dialing (DID) banktable record such as shown at 268 in FIG. 13.

An exemplary DID bank table record entry for the London callee is showngenerally at 291 in FIG. 14. The username field 281 and user domainfield 272 are as specified in the username and user domain fields 258and 260 of the dialing profile 276 shown in FIG. 12. The contents of theDID field 274 include an E.164 telephone number including a country code283, an area code 285, an exchange code 287 and a number 289. If theuser has multiple telephone numbers, then multiple records of the typeshown at 291 would be included in the DID bank table in the database 18,each having the same username and user domain, but different DID field274 contents reflecting the different telephone numbers associated withthat user.

Referring back to FIG. 8B, at block 269, if the RC processor circuit 200finds that the reformatted callee identifier produced at block 261 isfound in a record in the DID bank table, then the callee is a subscriberto the system and block 279 directs the RC processor circuit 200 to copythe contents of the corresponding username field 270 into a callee IDbuffer (not shown). Thus, the RC processor circuit 200 locates asubscriber username associated with the reformatted callee identifier.The processor is then directed to block 275 at point B in FIG. 8A.

Subscriber to Subscriber Calls Between Different Nodes

Referring back to FIG. 8A, block 275 then directs the RC processorcircuit 200 to determine whether or not the subscriber username isassociated with the same supernode as the caller. To do this, the RCprocessor circuit 200 determines whether or not the continent code (61)of the username stored in the callee ID buffer is the same as thecontinent code (61) of the username of the caller specified by thecaller identifier field 152 of the RC Request message shown in FIG. 6.If they are not the same, block 277 directs the RC processor circuit 200to set a call type flag (not shown) to indicate that the call is across-domain call. Then, block 350 directs the RC processor circuit 200to produce a routing message identifying the supernode in the systemwith which the callee is associated and to set a TTL for the call to themaximum value of 99999. The supernode in the system, with which thecallee is associated, is determined by using the callee username storedin the callee ID buffer to address a supernode table having records ofthe type as shown at 370 in FIG. 17.

Referring to FIG. 17, each prefix to supernode table record 370 has aprefix field 372 and a supernode address field 374. The prefix field 372includes the first n digits of the callee identifier. In this case n=1.The supernode address field 374 holds a code representing the IP addressor a fully qualified domain name of the supernode associated with thecode stored in the prefix field 372. Referring to FIG. 18, for example,if the prefix is 4, the supernode address associated with that prefix issp.lhr.digifonica.com, identifying the London supernode 21, for example.

Referring to FIG. 15, a generic routing message is shown generally at352 and includes a supplier prefix field 354, a delimiter field 356, acallee field 358, at least one route field 360, a time-to-live (TTL)field 362 and other fields 364. The supplier prefix field 354 holds acode for identifying supplier traffic. The delimiter field holds asymbol that delimits the supplier prefix code from the callee field 358and in this embodiment, the symbol is a number sign (#). The route field360 holds a domain name or an IP address of a gateway or supernode thatis to carry the call and the TTL field 362 holds a value representingthe number of seconds the call is permitted to be active, based onsubscriber available minutes and other billing parameters, for example.

Referring to FIG. 8A and FIG. 16, in this example the routing messageproduced by the RC processor circuit 200 at block 350 is shown generallyat 366 and includes only a callee field 358, a route field 360 and a TTLfield 362.

The callee field 358 holds the full username of the callee and the routefield 360, shown in FIG. 15, contains the identification of the domainwith which the callee is associated, i.e., sp.lhr.digifonica.com.

Having produced the routing message 366 as shown in FIG. 16A, referringback to FIG. 8A, block 351 then directs the RC processor circuit 200 tocheck the caller dialing profile (see FIG. 9) to determine whether ornot it contains lawful intercept fields (702, 704, 706, 708, 710) and ifso, to determine whether or not the determination information containedtherein meets intercept criteria. The intercept criteria may be that thelawful intercept flag field 702 (FIG. 9) contains a flag indicatinglawful intercept is enabled and whether the current date and time iswithin the period specified by the LI start date/time field contents 708and the LI stop date/time field contents 710, for example. If theintercept criteria are met, block 353 directs the RC processor circuit200 to append the contents of the lawful intercept fields 702, 704, 706,708, 710 to the routing message produced at block 350 to produce arouting message as shown in FIG. 16A. Generally, the determination ofwhether or not the destination information meets intercept criteria isdone prior to producing the routing message so that when the interceptcriteria are met, at least some of the intercept information, in thisembodiment all of it, can be included in the routing message.

If at block 351 in FIG. 8A, it is determined there are no lawfulintercept fields associated with the caller dialing profile or that theintercept criteria are not met, the processor does not append any lawfulintercept fields to the routing message produced at block 350 in FIG. 8Aand the routing message shown in FIG. 16 is sent to the call controller14 as shown at block 380. If the lawful intercept fields have beenappended, block 380 directs the RC processor circuit 200 to send therouting message shown in FIG. 16A to the call controller 14 (FIG. 1).

Referring back to FIG. 8B, if at block 257, the callee identifierspecified by the contents of the callee field 154 of the RC Requestmessage shown in FIG. 6 does not begin with an IDD, block 381 directsthe RC processor circuit 200 to determine whether or not the calleeidentifier begins with the same national dial digit code as assigned tothe caller. To do this, the processor is directed to refer to the callerdialing profile shown in FIG. 10. In the embodiment shown, the NDD code262 is the digit 1. Thus, if the callee identifier begins with the digit1, the RC processor circuit 200 is directed to block 382 in FIG. 8B.

Block 382 directs the RC processor circuit 200 to examine the calleeidentifier to determine whether or not digits following the NDD codeidentify an area code that is the same as any of the area codesidentified in the local area codes field 267 of the caller dialingprofile 276 shown in FIG. 10. If not, block 384 directs the RC processorcircuit 200 to set a call type variable (not shown) to a code indicatingthe call is a national code. If the digits identify an area code that isthe same as a local area code associated with the caller, block 386directs the RC processor circuit 200 to set the call type variable toindicate that the call type is a local call, national style. Afterexecuting blocks 384 or 386, block 388 directs the RC processor circuit200 to format the number dialed by removing the national dial digit(NDD) and prepending a caller country code identified by the countrycode field 266 of the caller dialing profile shown in FIG. 10. The RCprocessor circuit 200 is then directed to block 263 to perform theprocesses described above beginning at block 263.

If at block 381, the callee identifier does not begin with an NDD code,block 390 directs the RC processor circuit 200 to determine whether thecallee identifier begins with digits that identify the same area code asthe caller. Again, the reference for this is the caller profile shown inFIG. 10 and the RC processor circuit 200 determines whether or not thefirst few digits in the callee identifier identify an area codeidentified by the local area code field 267 of the caller profile. Ifso, then block 392 directs the RC processor circuit 200 to set the calltype to a code indicating the call is a local call and block 394 directsthe RC processor circuit 200 to prepend the caller country code to thecallee identifier, the caller country code being determined from thecountry code field 266 in the caller profile shown in FIG. 10. The RCprocessor circuit 200 is then directed to block 263 for processing asdescribed above beginning at block 263.

If at block 390, the callee identifier does not have the same area codeas the caller, block 396 directs the RC processor circuit 200 todetermine whether the callee identifier has the same number of digits asthe number of digits indicated in either the caller minimum local numberlength field 268 or the caller maximum local number length field 270 ofthe caller profile shown in FIG. 10. If so, then block 398 directs theRC processor circuit 200 to set the call type to local and block 400directs the processor to prepend to the callee identifier the callercountry code as indicated by the country code field 266 of the callerprofile shown in FIG. 10 followed by the caller area code as indicatedby the local area code field 267 of the caller profile shown in FIG. 10.The RC processor circuit 200 is then directed to block 263 for furtherprocessing as described above beginning at block 263.

If at block 396, the callee identifier has a length that does not matchthe length specified by the contents of the caller minimum local numberlength field 268 or the caller maximum local number length field 270,block 402 directs the RC processor circuit 200 to determine whether ornot the callee identifier identifies a valid username. To do this, theRC processor circuit 200 searches through the database of dialingprofiles to find a dialing profile having username field contents 258that match the callee identifier. If no match is found, block 404directs the RC processor circuit 200 to send an error message back tothe call controller (14). If at block 402, a dialing profile having ausername field 258 that matches the callee identifier is found, block406 directs the RC processor circuit 200 to set the call type to a codeindicating the call is a network call and the processor is directed toblock 275 of FIG. 8A, to continue processing the RC message handlerprocess 250.

From FIG. 8B, it will be appreciated that there are certain groups ofblocks of codes that direct the RC processor circuit 200 to determinewhether the callee identifier has certain features such as an IDD code,a NDD code, an area code and a length that meet certain criteria and toreformat the callee identifier as necessary into a predetermined targetformat including only a country code, area code, and a normal telephonenumber, for example, to cause the callee identifier to be compatiblewith the E.164 number plan standard, in this embodiment. This enablesthe RC processor circuit 200 directed by block 279 to have a consistentformat of callee identifiers for use in searching through the DID banktable records of the type shown in FIG. 13 to determine how to routecalls for subscriber to subscriber calls on the same system.

Subscriber to Non-Subscriber Calls

Not all calls will be subscriber-to-subscriber calls and this will bedetected by the RC processor circuit 200 when it executes block 269 ofFIG. 8B, and does not find a record that is associated with the calleein the DID bank table. When this occurs, the RC processor circuit 200 isdirected to block 408 which causes it to set the callee identifier equalto the reformatted callee identifier, i.e., the number compatible withthe E.164 standard. Then, block 410 directs the RC processor circuit 200to address a master list having records of the type shown in FIG. 19.

Each master list record includes a master list ID field 500, a dialingcode field 502, a country code field 504, a national sign number field506, a minimum length field 508, a maximum length field 510, a NDD field512, an IDD field 514 and a buffer rate field 516.

The master list ID field 500 holds a unique code such as 1019, forexample, identifying a route identification (route ID). The dialing codefield 502 holds a predetermined number pattern which the RC processorcircuit 200 uses at block 410 in FIG. 8B to find the master list recordhaving a dialing code matching the first few digits of the reformattedcallee identifier. The country code field 504 holds a numberrepresenting the country code associated with the record and thenational sign number field 506 holds a number representing the area codeassociated with the record. (It will be observed that the dialing codeis a combination of the contents of the country code field 504 and thenational sign number field 506.) The minimum length field 508 holds anumber representing the minimum number of digits that can be associatedwith the record and the maximum length field 51 holds a numberrepresenting the maximum number of digits in a number with which therecord may be compared. The NDD field 512 holds a number representing anaccess code used to make a call within the country specified by thecontents of the country code field 504 and the IDD field 514 holds anumber representing the international prefix needed to dial a call fromthe country indicated by the country code.

Thus, for example, a master list record may have a format as shown inFIG. 20 with exemplary field contents as shown.

Referring back to FIG. 8B, using the country code and area code portionsof the reformatted callee identifier that has been formatted forcompatibility with the E.164 standard, block 410 directs the RCprocessor circuit 200 to find a master list record such as the one shownin FIG. 20 having a dialing code that matches the country code and areacode of the callee identifier. Thus, in this example, the RC processorcircuit 200 would find a master list record having an ID field with thenumber 1019. This number may be also referred to as a route ID. Thus, aroute ID number is found in the master list record associated with apredetermined number pattern in the reformatted callee identifier.

After execution of block 410 in FIG. 8B, the process 250 continues asshown in FIG. 8D. Referring to FIG. 8D, block 412 directs the RCprocessor circuit 200 to use the route ID number to locate at least onesupplier record identifying a supplier operable to supply acommunications link for this route. To do this, block 412 directs the RCprocessor circuit 200 to search a supplier ID table having records ofthe type shown in FIG. 21.

Referring to FIG. 21, the supplier list records include a supplier IDfield 540, a route ID field 542, an optional prefix field 544, a routeidentifier field 546, a NDD/IDD rewrite field 548 and a rate field 550.The supplier ID field 540 holds a code identifying the name of thesupplier and the route ID field 542 holds a code for associating thesupplier record with a route, and hence with a master list record. Theprefix field 544 holds a string used to identify the supplier trafficand the route identifier field 546 holds an IP address of a gatewayoperated by the supplier indicated by the supplier ID field 540. TheNDD/IDD rewrite field 548 holds a code and the rate field 550 holds acode indicating the cost per second to the system operator to use theroute provided by the gateway specified by the contents of the routeidentifier field 546. Exemplary supplier records are shown in FIGS. 22,23 and 24 for the suppliers shown in FIG. 1 which may include Telus,Shaw and Sprint, respectively, for example.

Referring back to FIG. 8D, at block 412 the RC processor circuit 200finds all supplier records that identify the route ID found at block 410of FIG. 8B.

Referring back to FIG. 8D, block 560 directs the RC processor circuit200 to begin to produce routing messages of the type shown in FIG. 16.To do this, the RC processor circuit 200 loads a routing message bufferas shown in FIG. 25 with a supplier prefix of the least costly supplierwhere the least costly supplier is determined from the rate fields 550of the records associated with respective suppliers.

Referring to FIGS. 22-24, in the embodiment shown, the supplier “Telus”has the lowest number in the rate field 550 and therefore the prefix4973 associated with that supplier is loaded into the routing messagebuffer shown in FIG. 25 first. The prefix 4973 is then delimited by thenumber sign and the reformatted callee identifier is next loaded intothe routing message buffer. Then, the contents of the route identifierfield 546 of the record associated with the supplier Telus are added tothe message after an @ sign delimiter and then block 564 in FIG. 8Ddirects the RC processor circuit 200 to get a TTL value, which in thisembodiment may be 3600 seconds, for example. Block 566 then directs theRC processor circuit 200 to load this TTL value in the routing messagebuffer shown in FIG. 25. Accordingly, the first part of the routingmessage is shown generally at 570 in FIG. 25.

Referring back to FIG. 8D, block 568 directs the RC processor circuit200 back to block 560 and causes it to repeat blocks 560, 562, 564 and566 for each successive supplier until the routing message buffer isloaded with information pertaining to each supplier. Thus, the secondportion of the routing message is shown at 572 in FIG. 25 and thissecond portion relates to the second supplier identified by the recordshown in FIG. 23 and referring back to FIG. 25, the third portion of therouting message is shown at 574 which is associated with a thirdsupplier as indicated by the supplier record shown in FIG. 24.Consequently, referring to FIG. 25, the routing message buffer holds arouting message identifying a plurality of different suppliers able toprovide gateways to establish a communication link to permit the callerto contact the callee. Each of the suppliers is identified, in ascendingorder according the rates contained in the rate fields 550 of thesupplier list records shown in FIGS. 22-24, in this embodiment. Othercriteria for determining the order in which suppliers are listed in therouting message may include preferred supplier priorities which may beestablished based on service agreements, for example. In this caseadditional fields may be provided in respective supplier records to holdvalues representing supplier priority.

After the routing message buffer has been loaded as shown in FIG. 25,block 567 directs the RC processor circuit 200 to check the callerdialing profile shown in FIG. 10 to determine whether or not it containslawful intercept fields as shown in FIG. 9, and if so, to determinewhether or not the intercept criteria are met by checking whether thelawful intercept flag field 702 contains a flag indicating that lawfulintercept is enabled and checking whether the current date and time arewithin the period specified by the LI start date/time field contents 708and the LI stop date/time field contents 710. If the intercept criteriaare met, block 569 directs the RC processor circuit 200 to append thecontents of the lawful intercept fields 702, 704, 706, 708, 710 to therouting message stored in the routing message buffer, as shown in FIG.25A. Again, the determination of whether or not the destinationinformation meets intercept criteria is done prior to producing therouting message so that when the intercept criteria are met, at leastsome of the intercept information, in this embodiment all of it, can beincluded in the routing message.

If at block 567, it is determined there are no lawful intercept fieldsassociated with the caller dialing profile shown in FIG. 10 or that theintercept criteria are not met, the RC processor circuit 200 does notappend any lawful intercept fields to the routing message stored in therouting message buffer shown in FIG. 25.

Block 568 then directs the RC processor circuit 200 to send the contentsof the routing message buffer, i.e. the routing message shown in FIG. 25or 25A, to the call controller 14 in FIG. 1.

Subscriber to Subscriber Calls within the Same Node

Referring back to FIG. 8A, if at block 275, the callee identifier storedin the callee ID buffer has a prefix that identifies the same supernodeas that associated with the caller, block 600 directs the RC processorcircuit 200 to use the callee identifier to locate and retrieve adialing profile for the callee identified by the callee identifier. Thedialing profile is of the type shown in FIG. 9, and may contain data asshown in FIG. 11, for example. Block 602 of FIG. 8A directs the RCprocessor circuit 200 to get call block, call forward and voicemailtables from the database 18 based on the username identified in thecallee profile retrieved by the RC processor circuit at block 600. Callblock, call forward and voicemail tables have records as shown in FIGS.26, 28 and 30 for example.

Referring to FIG. 26, the call block records include a username field604 and a block pattern field 606. The username field holds a usernamematching the username in the username field 258 of the dialing profileassociated with the callee and the block pattern field 606 holds one ormore E.164-compatible numbers or usernames identifying PSTN numbers orsystem subscribers from whom the subscriber identified by the contentsof the username field 604 does not wish to receive calls.

Referring back to FIG. 8A and referring to FIG. 27, block 608 directsthe RC processor circuit 200 to determine whether or not the calleridentifier matches a block pattern stored in the block pattern field 606of the call block record associated with the callee identified by thecontents of the username field 604 in FIG. 26. If the caller identifiermatches a block pattern stored in the block pattern field 606, block 610directs the RC processor circuit 200 to send a drop call ornon-completion message to the call controller (14) and the process isended. If the caller identifier does not match a block patternassociated with the callee, block 612 directs the RC processor circuit200 to determine whether or not call forwarding is required.

Referring to FIG. 28, records in the call forwarding table include ausername field 614, a destination number field 616, a destination numberfield 616 and a sequence number field 618. The username field 614 storesa code representing a subscriber with which the record is associated.The destination number field 616 holds a username or number representinga number to which the current call should be forwarded and the sequencenumber field 618 holds an integer number indicating the order in whichthe username associated with the corresponding destination number field616 should be attempted for call forwarding. The call forwarding tablemay have a plurality of records for a given user. The RC processorcircuit 200 uses the contents of the sequence number field 618 toconsider the records for a given subscriber in order. As will beappreciated below, this enables the call forwarding numbers to be triedin an ordered sequence.

Referring back to FIG. 8A and referring to FIG. 28, if at block 612 inFIG. 8A, the call forwarding record for the callee identified by thecallee identifier contains no contents in the destination number field616 and accordingly no contents in the sequence number field 618, thereare no call forwarding entries and the RC processor circuit 200 isdirected to load the routing message buffer shown in FIG. 32 with thecallee username and domain, as shown at 650 in FIG. 32. The processor isthen directed to block 620 in FIG. 8C.

If there are contents in the destination number field of the callforwarding record as shown in FIG. 29, block 622 shown in FIG. 8Adirects the RC processor circuit 200 to search the dialing profile tableto find a dialing profile record of the type shown in FIG. 9, for theuser identified in the destination number field 616 in the callforwarding table record of FIG. 29 and to store the contents of thedestination number field in the routing message buffer shown in FIG. 32.The RC processor circuit 200 is then directed to load the contents ofthe domain field 260 shown in FIG. 9 associated with the usernamespecified by the contents of the destination number field 616 of FIG. 29into the routing message buffer as shown at 652 in FIG. 32. This processis repeated for each call forwarding record associated with the calleeidentified by the callee identifier to add to the routing message bufferall call forwarding usernames and domains associated with the callee.

Referring to FIG. 8C, at block 620 the processor is directed todetermine whether or not the user identified by the callee identifierhas paid for voicemail service and this is done by checking to seewhether or not a flag is set in a voicemail record of the type shown inFIG. 30 in a voicemail table stored in the database 18 in FIG. 1.

Referring to FIG. 30, voicemail table records include a username field624, a voicemail server field 626, a seconds-to-voicemail field 628 andan enable field 630. The username field 624 stores the username of thesubscriber who purchased the service. The voicemail server field 626holds a code identifying an IP address or a fully qualified domain name(FQDN) of a voicemail server associated with the subscriber identifiedby the username field 624. The seconds-to-voicemail field 628 holds acode identifying the time to wait before engaging voicemail and theenable field 630 holds a code representing whether or not voicemail isenabled for the user identified by the contents of the username field624. Therefore, referring back to FIG. 8C, at block 620 the processorsearches for a voicemail record as shown in FIG. 31 having usernamefield 624 contents matching the callee identifier and looks at thecontents of the enabled field 630 to determine whether or not voicemailis enabled. If voicemail is enabled, then block 640 in FIG. 8C directsthe processor to store the contents of the voicemail server field 626 ofFIG. 31 and the contents of the seconds to voicemail field 628 of FIG.31 in the routing message buffer as shown at 654 in FIG. 32. Referringback to FIG. 8C, block 642 then directs the processor to get time tolive (TTL) values for each route specified by the routing messageaccording to any of a plurality of criteria such as, for example, thecost of routing and the user's account balance. These TTL values arethen appended to corresponding routes already stored in the routingmessage buffer.

Block 644 of FIG. 8C then directs the RC processor circuit 200 to storethe IP address of the current supernode in the routing message buffer asshown at 656 in FIG. 32. An exemplary routing message is shown in therouting message buffer shown in FIG. 32.

Block 645 of FIG. 8C then directs the processor to check the callerdialing profile shown in FIG. 10 to determine whether or not it containslawful intercept fields of the type shown in FIG. 9 and if so, todetermine whether or not the intercept criteria are met. In thisembodiment, this includes determining whether the lawful intercept flagfield 702 contains a flag indicating that lawful intercept is enabledand checking whether the current date and time is within the periodspecified by the LI start date/time field contents 708 and the LI stopdate/time field contents 710. If the intercept criteria are met, block647 directs the RC processor circuit 200 to append the contents of thelawful intercept fields 702, 704, 706, 708, 710 to the routing messageshown in FIG. 32A to produce a routing message with lawful interceptfield contents, as shown in FIG. 32A. Again, the determination ofwhether or not the destination information meets intercept criteria isdone prior to producing the routing message so that when the interceptcriteria are met, at least some of the intercept information, in thisembodiment all of it, can be included in the routing message.

Referring back to FIG. 8C, if at block 645, it is determined there areno lawful intercept fields associated with the caller dialing profile ofFIG. 10 or that the intercept criteria are not met after producing therouting message shown in FIG. 32A the processor is directed to block 649which causes the processor to check the callee dialing profile shown inFIG. 11 to determine whether or not it contains lawful intercept fieldsof the type shown in FIG. 9 and if so, to determine whether or not theintercept criteria are met by checking whether the current date and timeis within the period specified by the LI start date/time field contents708 and the LI stop date/time field contents 710 of the callee dialingprofile. If the intercept criteria are met, block 651 directs the RCprocessor circuit 200 to append the contents of the lawful interceptfields 702, 704, 706, 708, 710 associated with the callee dialingprofile to the routing message shown in FIG. 32A to produce a routingmessage. If at block 649 of FIG. 8C, it is determined there are nolawful intercept fields associated with the callee dialing profile orthat the intercept criteria are not met, no lawful intercept fieldsassociated with the callee are appended to the routing message shown inFIG. 32 or 32A. Referring back to FIG. 8C, block 646 then directs the RCprocessor circuit 200 to send the routing message to the call controller14.

Response to Routing Message

Referring back to FIG. 1, the routing message, whether of the type shownin FIG. 16, 16A, 25, 25A, 32, 32A or 32B, is received at the callcontroller 14. Referring to FIG. 33, when a routing message is receivedat the call controller, the routing message handler 122 is invoked atthe call controller. The routing message handler is shown in detail inFIG. 33.

Referring to FIG. 33, the routing message handler begins with a firstblock 1200 that directs the processor circuit to determine whether therouting message includes lawful intercept fields. If not, the processoris directed to block 1206 which causes it to invoke a call handlingroutine shown in FIG. 34. Referring to FIG. 34, as a first step in thecall handling routine, a message 1100 is sent from the call controller14 to the media relay 17, the message including the caller telephone IPaddress and UDP port as determined from the caller IP address field 67and caller UDP port field 69 in the SIP Invite message shown in FIG. 3.

The specific media relay 17 to which the message 1100 is sent may beselected from a pool of available media relays and such media relays maybe at any geographical location. The purpose of the message 1100 is toadvise the media relay that a call is desired to be set up tocommunicate with the IP address and UDP number of the caller telephone.

A media relay selected from media relays located at a geographicallocation that facilitates communication at a desired quality of servicebetween the media relay 17 and the caller telephone 12 and calleetelephone 15 may provide the best service. Alternatively, media relaysmay be pre-assigned or pre-associated with users by including andpopulating media relay fields of the dialing profiles of users, such asshown at 1150 in FIG. 9, identifying one or more media relays throughwhich calls associated with the associated user are to be directed. Inthis case, the identifications of possible media relays obtained fromthe media relay fields 1150 may be sent to the call controller inadditional fields in the routing message. These media relay fields areshown at 1152 in FIGS. 16, 16A, 25, 25A, 32, 32A and 32B. In essence,the media relay through which communications involving thecommunications involving the subscriber will be conducted is identifiedin response to the routing message.

Referring back to FIG. 34, in this case, the message 1100 may be sent ina polling fashion to all media relays identified by the media relayfields 1150, until one responds. Alternatively, the message 1100 may besent simultaneously to all of the media relays.

In response, in the case where the media relay is known or is involvedin polling as described above, the media relay 17 to which the message1100 is sent sends a media relay status message 1102 back to the callcontroller 14, the message including a media relay IP address and UDPport number at which the media relay will establish a UDP connection tothe callee telephone 15. Audio data to/from the callee telephone 15 willbe transmitted over this connection. In the case where the message 1100is sent to a plurality of media relays, the first one to respond with amedia relay status message is the one through which the call will becarried. Media relay status messages from the remaining media relays canbe ignored.

After the media relay status message 1102 is received at the callcontroller, the call controller 14 then sends a SIP Invite message 1104of the type shown in FIG. 3 to the callee telephone 15, including thecontents of the caller and callee identifier fields (60 and 62), thecall identifier field (65) and the media relay IP address and the mediarelay UDP port number assigned to the audio path connection with thecallee telephone 15, to invite the callee telephone to establish aconnection with the media relay 17.

The purpose of the SIP Invite message 1104 is to advise the calleetelephone of the caller and call ID and of the IP address and UDP portnumber of the media relay through which the callee telephone should sendand receive audio data.

The callee telephone 15 stores the media relay IP address and assignedUDP port number in the audio path IP address buffer 47 shown in FIG. 2and configures itself to create a socket between the media relay IP/UDPaddress and the callee telephone IP address and a UDP port number thatthe callee telephone 15 desires to use as an audio path to the callertelephone. Instead of being sent or received directly to or from thecaller telephone, the callee telephone 15 will send and receive audiodata from the media relay. To indicate this, the callee telephone 15sends a SIP OK message 1106 back to the call controller 14, the messageincluding the callee IP address and UDP port number from its IP addressfield (53 in FIG. 3) at which the callee telephone 15 will establish anaudio path connection with the media relay 17. The purpose of this SIPOK message 1106 is to advise the call controller of the IP address andUDP port number through which the media relay should send and receiveaudio data to and from the callee telephone.

The call controller 14 then sends a message 1108 to the media relay 17including the IP address and UDP port number that the callee telephone15 will use for the audio path connection with the media relay. Thepurpose of the message 1108 is to advise the media relay of the IPaddress and UDP port number through which it should send and receiveaudio data to and from the callee telephone.

The media relay 17 then determines a UDP port through which it willcarry audio data to and from the caller telephone 12 and sends a message1110 to the call controller (14), the message including the media relayIP address and the media relay UDP port number the media relay will useto carry audio to and from the caller telephone 12. The purpose of thismessage 1110 is to advise the call controller 14 of the IP address andUDP port number through which it expects to transfer audio data to andfrom the caller telephone.

The call controller 14 then sends a SIP OK message 1112 to the callertelephone 12 to indicate that the call may now proceed. The SIP OKmessage includes the caller and callee usernames, the call ID and themedia relay 17 IP address and the UDP port number assigned to the audioconnection with the caller telephone 12. The purpose of this SIP OKmessage 1112 is to advise the caller telephone 12 of the IP address andUDP port number through which it should exchange audio data with themedia relay 17.

If the routing message is of the type shown in FIG. 25 where there are aplurality of suppliers available, the call handling routine proceeds asdescribed above with the exception that instead of communicating withthe callee telephone directly, the call controller 14 communicates witha gateway provided by a supplier. If a SIP OK message is not receivedback from the first gateway, the processor is directed to send the SIPInvite message 1104 to a gateway of the next indicated supplier. Forexample, the call controller 14 sends the SIP Invite message 1104 to thefirst supplier, in this case Telus, to determine whether or not Telus isable to handle the call. If Telus does not send back a SIP OK message1106 within a specified time or sends a message indicating that it isnot able to handle the call, the call controller proceeds to send a SIPInvite message 1104 to the next supplier, in this case Shaw. The processis repeated until one of the suppliers responds with a SIP OK message106 indicating that it is available to carry the call and the processproceeds as shown in connection with messages 1108, 1110 and 1112. Forexample, the supplier “Telus” sends back a SIP OK message and thusprovides a gateway to the PSTN at IP address 72.64.39.58 as provided bythe routing message from the contents of the route identifier field 546of the corresponding supplier record shown in FIG. 22.

Referring back to FIG. 1, if the call controller 14 receives a messageof the type shown in FIG. 32, i.e., a type that has one call forwardingnumber and/or a voicemail number, the call controller attempts toestablish a call (using SIP Invite message 1104) to the callee telephone15 and if no call is established (i.e., message 1106 is not received)within a pre-determined time, the call controller 14 attempts toestablish a call with the next user identified in the call routingmessage, by sending a SIP invite message like message 1104 to the nextuser. This process is repeated until all call forwarding possibilitieshave been exhausted, in which case an audio path is established with thevoicemail server 19 identified in the routing message. The voicemailserver 19 sends the SIP OK message 1106 in response to receipt of theSIP invite message 1104 and functions as described above in connectionwith the callee telephone 15 to permit an outgoing audio messageprovided by the voicemail server to be heard by the caller and to permitthe caller to record an audio message on the voicemail server.

When audio paths are established, a call timer (not shown) maintained bythe call controller logs the start date and time of the call and logsthe call ID and adds an active call record of the type shown in FIG. 35to an active call list, maintained by the call controller.

In this embodiment, the call controller active call record shown in FIG.35 includes a call ID field 1300, a caller IP address field 1302, acaller port field 1304, a callee IP address field 1306, a callee portfield 1308, a media relay ID field 1310, a media relay caller port field1312 and a media relay callee port field 1314. The contents of the callID field 1300 are established at block 136 in FIG. 5. The contents ofthe caller IP address field 1302 are established from the contents ofthe caller IP address field 67 of the SIP invite message shown in FIG.3. The contents of the caller port field 1304 are established from thecaller UDP port field 69 of the SIP invite message shown in FIG. 3. Thecontents of the callee IP address field 1306 and callee port field 1308are established from the SIP OK message 1106 shown in FIG. 34.

The media relay ID field 1310 is populated with an identification of themedia relay handling the call. In the example shown, the media relay isnumber 42. The contents of the media relay caller port field areobtained from the message 1110 shown in FIG. 34 and the contents in themedia relay callee port field 1314 are obtained from the media relaystatus message 1102 shown in FIG. 34. Each time a call is established,an active call record of the type shown in FIG. 35 is added to an activecall log maintained by the call controller.

The routing controller also maintains an active call log containingactive call records however the active call records maintained by therouting controller are different from the active call records held bythe call controller. For example, referring to FIG. 36, an active callrecord held by the routing controller includes a call ID field 1316, acaller field 1318, a callee field 1320 and a call controller ID field1322. Information for populating these fields may be received in amessage (not shown) transmitted from the call controller to the routingcontroller after an active call record has been entered into the activecall log of the call controller.

The message from the call controller 14 to the routing controller 16,indicating that an active call has been established may include thecontents of the call ID field 1300 shown in FIG. 35 and a callcontroller unique ID number held by the call controller. The routingcontroller 16 matches the call ID with the caller and callee user namescontained in the original call routing message (FIG. 16, 16A, 25, 25A,32, 32A, 32B) that caused the call controller 14 to route the call, topopulate the caller and callee fields 1318 and 1320 shown in FIG. 36,respectively. It will be appreciated that a plurality of callcontrollers may be associated with a single routing controller, in whichcase the call controller ID allows the routing controller to uniquelyidentify the call controller associated with the call ID indicated bythe contents of the call ID field 1316. In the example shown, the callcontroller is number 61.

The active call records facilitate intercepting a call already inprogress, as will be described below.

Referring back to FIG. 33, if at block 1200 it is determined that therouting message has lawful intercept fields, block 1202 directs the callcontroller circuit 100 (FIG. 4) to send a SIP Invite message as shown inFIG. 37 to a mediation device identified by the mediation device IPaddress in the routing message as obtained from the user dialing profileMD1 address field 704 as shown at 256 in FIG. 9. Referring to FIG. 37,the SIP Invite message includes caller and callee identifier fields1020, 1022, a call ID field 1024, a warrant ID field 1026 and otherintercept related information fields 1028, if desired. The caller,callee and call ID field contents 1020, 1022, and 1024 are obtained fromthe original SIP Invite message shown in FIG. 6. The contents of thewarrant ID field 1026 and intercept related info fields 1028 areobtained from the routing message which would be of the type shown inFIG. 16A, 25A, 32A or 32B.

Referring back to FIG. 33, block 1204 then directs the call controller14 to receive a reply message, as shown in FIG. 38, from the mediationdevice 31. The reply message is a SIP OK message that includes caller,callee, and call ID fields 1040, 1042, 1044 as described above andfurther includes a mediation device IP address field 1046 and amediation device UDP caller port number field 1048 and a UDP callee portnumber field 1050 identifying UDP ports at the mediation device IPaddress to which the media relay is to send copies of audio data streamsreceived from the caller and callee telephones respectively. Block 1206then directs the call controller to execute the call handling routineshown in FIG. 34 with the exception that the message 1100 additionallyincludes the contents of the mediation device IP address field 1046, themediation device UDP caller port number field 1048 and the UDP calleeport number field 1050 of the SIP OK message shown in FIG. 38.

All other messages are the same as described above in connection withthe call handling routine as shown in FIG. 34, but in response toreceiving the additional information in the message 1100, the mediarelay automatically configures itself to provide for copying the audiodata received from both the caller telephone and the callee telephone tothe mediation device IP address and the UDP caller port number and theUDP callee port number respectively.

Referring back to FIG. 1, as audio data originating at the callertelephone 12 and callee telephone 15 passes through the media relay 17,this data is copied to the mediation device UDP port for the caller andthe mediation device UDP port for the callee, as indicated by the SIPinvite message 1100. This enables law enforcement agencies to monitoraudio communications between the caller and callee and/or to record suchcommunications at the mediation device.

Thus, when the determination information in the dialing profile meetsintercept criteria, the call controller communicates with the mediarelay through which communications involving the subscriber whosecommunications are to be monitored will be handled to cause the mediarelay to send a copy of such communications to a mediation devicespecified by the destination information included in the interceptinformation associated with the dialing profile associated with thesubscriber whose communications are to be monitored.

Terminating the Call

In the event that either the caller or the callee terminates a call, thetelephone of the terminating party sends a SIP Bye message to the callcontroller 14. An exemplary SIP Bye message is shown at 900 in FIG. 39and includes a caller field 902, a callee field 904 and a call ID field906. The caller field 902 holds the caller username, the callee field904 holds a PSTN compatible number or username, and the call ID field906 holds a unique call identifier field of the type shown in the callidentifier field 65 of the SIP Invite message shown in FIG. 3.

Thus, for example, referring to FIG. 40, a SIP Bye message for theCalgary callee is shown generally at 908 and the caller field 902 holdsa username identifying the Vancouver caller, in this case 2001 10508667, the callee field 904 holds a username identifying the Calgarycallee, in this case 2001 1050 2222, and the call ID field 906 holds thecode FA10@192.168.0.20, which is the call ID for the call.

The SIP Bye message shown in FIG. 40 is received at the call controller14 and the call controller executes a process as shown generally at 910in FIG. 41. The process includes a first block 912 that directs the callcontroller circuit (100) to copy the caller, callee and call ID fieldcontents from the SIP Bye message 900 shown in FIG. 39 received from theterminating party to corresponding fields of an RC stop message buffer(not shown). Block 914 then directs the call controller circuit 100 tocopy the call start time from the call timer and to obtain a Call Stoptime from the call timer. Block 916 then directs the call controller tocalculate a communication session time by determining the difference intime between the call start time and the Call Stop time. Thiscommunication session time is then stored in a corresponding field ofthe RC Call Stop message buffer. Block 918 then directs the callcontroller circuit 100 to populate the route field with the IP addressof the gateway supplier, if any. An RC Call Stop message produced asdescribed above is shown generally at 1000 in FIG. 42. An RC Call Stopmessage specifically associated with the call made to the Calgary calleeis shown generally at 1021 in FIG. 43.

Referring to FIG. 42, the RC call stop message 1000 includes a callerfield 1002, callee field 1004, a call ID field 1006, an account starttime field 1008, an account stop time field 1010, a communicationsession time field 1012 and a route field 1014. The caller field 1002holds a username, the callee field 1004 holds a PSTN-compatible numberor system number, the call ID field 1006 holds the unique callidentifier received from the SIP Invite message shown in FIG. 3, theaccount start time field 1008 holds the date and start time of the call,the account stop time field 1010 holds the date and time the call ended,the communication session time field 1012 holds a value representing thedifference between the start time and the stop time, in seconds, and theroute field 1014 holds the IP address for a gateway, if a gateway isused to establish the call.

Referring to FIG. 43, an exemplary RC call stop message for the Calgarycallee is shown generally at 1021. In this example the caller field 1002holds the username 2001 1050 8667 identifying the Vancouver caller andthe callee field 1004 holds the username 2001 1050 2222 identifying theCalgary callee. The contents of the call ID field 1006 areFA10@192.168.0.20. The contents of the account start time field 1008 are2006-12-30 12:12:12 and the contents of the account stop time field 1010are 2006-12-30 12:12:14. The contents of the communication session timefield 1012 are 2 to indicate 2 seconds call duration and the contents ofthe route field are blank but would be 72.64.39.58 if the “Telus”gateway were used, for example.

Referring back to FIG. 41, after having produced an RC Call Stopmessage, block 920 directs the call controller circuit 100 to send theRC stop message contained in the RC Call Stop message buffer to therouting controller (16).

The RC (16) receives the Call Stop message and a routing controller CallStop message process (not shown) is invoked at the routing controller todeal with charges and billing for the call.

Block 922 directs the call controller circuit 100 to send a Bye messageto the party that did not terminate the call i.e. to the non-terminatingparty.

Block 924 then directs the call controller circuit 100 to send a SIP Byemessage of the type shown in FIG. 39 to the media relay 17 to cause themedia relay to disconnect the audio path sockets associated with thecaller telephone IP/UDP address and the callee telephone IP/UDP address.In disconnecting these communication sockets, the media relay 17 deletesassociations between the caller telephone IP/UDP address media relaycaller IP/UDP address and between the caller telephone IP/UDP addressand media relay callee IP/UDP address.

If the media relay (17) was configured for lawful intercept, block 926of FIG. 41 then directs the call controller circuit 100 to send a SIPBye message of the type shown in FIG. 39 to the mediation device 31 toinform the mediation device that the call has ended and to disconnectcommunication sockets between the media relay caller and callee IP/UDPport addresses and the IP/UDP port address to which the audio datareceived at the caller and callee IP/UDP port addresses were beingcopied.

It will be appreciated that in the foregoing description, the componentsdescribed cooperate to detect a requirement for intercept at the time acall is set up. In the following description an explanation is providedto describe how to intercept a call while the call is in progress.

Intercepting a Call in Progress

Referring back to FIG. 1, to intercept a call while the call is inprogress, the law enforcement authority 293 may communicate with amediation device, or may communicate with the call controller or maycommunicate with the routing controller or may communicate with ahandover interface that communicates with any of the foregoingcomponents to cause the routing controller to receive a law enforcementauthority (LEA) intercept request message including interceptinformation, such as that which would be associated with fields 702-710in FIG. 9, for example.

In response to receipt of a LEA intercept request message, the routingcontroller LEA request message handler shown at 1400 in FIG. 44 isinvoked.

The LEA request message handler 1400 begins with a first block 1402 thatdirects the routing controller processor circuit to communicate with thedatabase 18 in which dialing profile records of the type shown in FIG. 9are stored to find a dialing profile associated with the user whosecalls are to be monitored.

If the username is not known, but a DID number (i.e., a PSTN number) isknown, the routing controller may cause a search through the DID banktable records of the type shown in FIG. 13, for example to find ausername associated with a DID number. If the username is not known buta name and address is known, other records such as billing records (notshown) associating names and addresses with usernames may be searched tofind a username associated with a given name and/or address of a personwhose calls are to be intercepted. Regardless of the informationavailable, to facilitate call interception any way of finding the uniquedialing profile associated with the user whose calls are to beintercepted is a first step to facilitating call interception, in thisembodiment.

Once the dialing profile is located, block 1404 directs the routingcontroller processor circuit to associate the intercept information withthe dialing profile by appending and/or populating the lawful interceptfields of the dialing profile with such information as provided in theLEA intercept request message.

Block 1406 then directs the routing controller processor circuit todetermine whether the intercept criteria are met by the interceptinformation now included in the dialing profile. This is done bydetermining whether the LI flag (702) is on, and the current date andtime is within the LI start stop date/time ranges. If the interceptcriteria are not met, the process is ended. Otherwise the processor isdirected to block 1408.

Block 1408 directs the routing controller processor circuit to use theusername of the dialing profile found at block 1402 to search caller andcallee fields of routing controller active call records shown in FIG. 36that have contents matching the username associated with the dialingprofile. If no such record is found, the user is not currently engagedin a call and the process is ended. If the user is engaged in a call,the routing controller active call record will be found. Block 1410 thendirects the routing controller processor circuit to find the callcontroller id and call id of the associated call, from the routingcontroller active call record shown in FIG. 36.

Block 1412 then directs the routing controller processor circuit totransmit an in-call intercept message to the call controller identifiedby the contents of the call controller id field 1322 of the routingcontroller active call record. The in-call intercept message includesthe call id as determined from the routing controller active call recordand the IP address of the mediation device associated with the lawenforcement authority interested in intercepting the call. The IPaddress of the mediation device may be obtained from the law enforcementauthority request message, or the dialing profile, for example.

Block 1414 then directs the routing controller processor circuit to waita specified time to receive a call controller intercept status messageback from the call controller indicating whether or not the interceptfunction has been activated.

Referring to FIG. 45, upon receipt of an in-call intercept message atthe call controller (14) the call controller executes an in-callintercept message handler shown generally at 1450. The in-call interceptmessage handler 1450 begins with a first block 1452 that directs thecall controller processor circuit to send a SIP invite message to themediation device associated with the IP address of the mediation device,received in the in-call intercept message.

Block 1454 then directs the call controller processor circuit to receivean IP address and callee and caller UDP port numbers from the mediationdevice, where this IP address and UDP port numbers are network locationsat which the mediation device will expect to receive audio data streamsfrom the media relay through which the call is carried.

Block 1456 then directs the call controller processor circuit toidentify a media relay through which communications to be monitored arebeing conducted by using the username of the subscriber whosecommunications are to be monitored to locate an active call record inthe call controller active call list to locate a media relay identifiersuch as the IP address of the media relay indicated by the contents ofthe media relay ID field 1310 of the call controller active call recordshown in FIG. 35. The call controller processor circuit is then directedto send an intercept request message to the media relay (17) that ishandling the call. The intercept request message includes the mediationdevice IP address and caller and callee UDP port numbers to identify tothe media relay (17) the mediation device IP address and UDP portnumber(s) at which it expects to receive a copy of the audio data streamfrom the caller and callee respectively.

In response, the media relay establishes internal connections betweenthe caller and callee IP addresses and UDP ports and callee IP addressand UDP port of the mediation device. Then, the media relay sends amedia relay status message back to the call controller indicatingwhether or not internal connections have been established and that callintercept has been initiated.

As seen at block 1458, the call controller processor circuit is directedto receive the media relay status message and block 1460 directs thecall controller processor circuit to send a call controller interceptstatus message back to the routing controller to indicate that the callintercept function has been established. The routing controller maycommunicate this status back to the law enforcement authority thatissued the law enforcement authority request message. In the meantime,communications involving the caller or callee whose communications areto be monitored, which travel through the media relay, are copied andsent to the mediation device.

Thus, after associating intercept information with the dialing profileof the subscriber whose communications are to be monitored, when thedetermination information included in the intercept information meetsintercept criteria, the call controller communicates with the mediarelay through which the communications of the subscriber whosecommunications are to be monitored to cause such media relay to send acopy of such communications to a mediation device specified by thedestination information included in the intercept information.

When the call is ended, the call is shut down in the same way asdescribed above.

Should the law enforcement authority desire to cease interception of thecall during the call, an LEA request message requesting that theintercept function be stopped is sent to the routing controller from thelaw enforcement authority through any of the paths described above. Thisinvokes the LEA request message handler such as shown in FIG. 44 whichcauses the routing controller processor circuit to execute blocks 1402,1404. At block 1404, the routing controller processor circuit isdirected to change the contents of the lawful intercept fields to atleast set the lawful intercept flag (702 in FIG. 9) inactive.

Then, at block 1406, the intercept criteria are not met and theprocessor is directed to block 1416, which causes the routing controllerprocessor circuit to determine whether or not an interception functionis in progress. This can be determined, for example, by maintainingevidence of the receipt of the confirmation message from the callcontroller, received at block 1414 of the LEA request message handler1400.

If an intercept is not in progress, the LEA request message handler 1400is ended.

If an intercept if in progress, block 1418 directs the routingcontroller processor circuit to execute an in-call intercept shut downroutine as shown at 1500 in FIG. 46. The in-call intercept shut downroutine begins with a first block 1502 which directs the routingcontroller processor circuit to locate the routing controller activecall record having caller or callee field contents equal to the usernameindicated in the dialing profile found at bock 1402 of the LEA requestmessage handler 1400 shown in FIG. 44. Having found the active callrecord, block 1504 directs the routing controller processor circuit tofind, in the routing controller active call record shown in FIG. 36, thecall controller id (1322) and the call id (1316) associated with thecall. Block 1506 then directs the routing controller processor circuitto send a cease intercept message (not shown) to the call controlleridentified by the call controller id determined at block 1504. Thiscease intercept message includes the call id determined at block 1504and an identification of the mediation device, the identification beingobtained from the MD1 address field (704 in FIG. 9) of the dialingprofile for the user whose calls are currently being intercepted. Block1508 then directs the routing controller processor circuit to wait aspecified time to receive a confirmation message from the callcontroller to indicate that the intercept function has been shut down.

Referring to FIG. 47, upon receipt of the cease intercept message at thecall controller (14), a cease intercept message handler 1520 is invokedat the call controller. The cease intercept message handler 1520 beginswith a first block 1522 that directs the call controller processorcircuit to send a SIP stop message to the mediation device identified inthe cease intercept message received from the routing controller. Inresponse to the SIP stop message, the mediation device stops receivingaudio data and sends a confirmation message back to the call controller.

Block 1524 directs the call controller processor circuit to receive theconfirmation message back from the mediation device.

Block 1526 then directs the call controller processor circuit to send astop intercept message to the media relay 17 identified by the contentsof the media relay ID field 1310 of the active call record shown in FIG.35. The stop intercept message includes the contents of the media relaycaller port ID field 1312 and media relay callee port field 1314included in the active call record and identifies to the media relaywhich ports to shut down. In response to the stop intercept message, themedia relay 17 disconnects the connections between the media relaycaller port and the mediation device port that was receiving the audiodata from the caller and the connection between the media relay calleeport and the mediation device port that was receiving audio data fromthe callee. The media relay then sends an MR stop status message to thecall controller.

Block 1528 directs the call controller processor circuit to receive theMR stop status message and block 1530 directs the call controller tosend a stop status message to the routing controller 16.

In an alternative embodiment, the routing controller does not maintainactive call records but each call controller does. In such anembodiment, blocks 1408 and 1410 of FIG. 44 are replaced with a singleblock 1600 that directs the routing controller processor circuit to polleach call controller to determine whether or not its active call listcontains an entry having caller or callee field contents equal to theusername determined from the dialing profile located at block 1402.

If any of the polled call controllers has such a record, that callcontroller transmits a response message back to the routing controller,the response message including a call controller ID identifying thatcall controller. More than one call controller may have an active callrecord having caller or callee field contents equal to the usernamedetermined from the user profile. Such would be the case in a conferencecall, for example.

The routing controller processor circuit then executes blocks 1412 and1414 as described above or the process is ended if none of the polledcall controllers contains a call record with caller and callee fieldcontents matching the username determined from the dialing profilelocated at block 1402.

In effect therefore, block 1600 provides an alternate way of findingcall controllers that are currently carrying a call associated with theuser of interest.

In another embodiment, an interface to the routing controller and/or thecall controller may be provided to enable law enforcement authorities tohave direct access or a copy of the active call list maintained by thecall controller and/or routing controller.

From the foregoing, it will be appreciated that indications of whetheror not communications of a subscriber to the system are to be monitoredare provided by law enforcement agencies directly into a subscriberdialing profile shown in FIG. 9. This dialing profile is used to route acall involving the subscriber and is checked for lawful interceptrequirements to determine whether or not the media relay should copyaudio data associated with the call to a mediation device for lawfulmonitoring and/or recording purposes.

While the system has been described in connection with the monitoring ofaudio streams, it may similarly be used for monitoring any other datastreams such as pure data and/or video or multimedia data, for example,between subscribers to the system or between a subscriber and anon-subscriber to the system.

While specific embodiments of the invention have been described andillustrated, such embodiments should be considered illustrative of theinvention only and not as limiting the invention as construed inaccordance with the accompanying claims.

What is claimed is:
 1. A method for intercepting communications in an Internet Protocol (IP) network system in which communications between a subscriber of the system and another party occur through a media relay to which the subscriber and the another party address their communications destined for each other and which relays the communications between the subscriber and the another party, the method comprising: determining whether determination information associated with a subscriber dialing profile associated with the subscriber meets intercept criteria; when the determination information meets the intercept criteria, causing the same media relay through which communications between the subscriber and the another party are relayed to produce a copy of the communications between the subscriber and the another party, while the same media relay relays communications between the subscriber and the another party; and causing the same media relay to send the copy to a mediation device identified by destination information associated with the subscriber dialing profile. 